[Pgpool-hackers] First try at rephrasing the documentation

[Tatsuo Ishii]

> The Wednesday 05 January 2011 02:37:52, Tatsuo Ishii wrote :
>> >> I proofreaded Marc's rewrite. It's mostly really good, but there are a
>> >> few mistakes. Patch attached fixes them. The whole new file is also
>> >> attached (with Marc's patch and mine).
>> >> 
>> >> So I think all is need is to put the last bit of informations Tatsuo
>> >> gave you, to have a complete file.
>> >> 
>> >> Thanks for your work.
>> > 
>> > Here is another patch (version 3) to be applied on top of this one.
>> > 
>> > There are 3 items left (missing answers):
>> > 
>> > 
>> > In the replication mode or master/slave mode, trust, clear text
>> > 
>> >       password, and pam methods are supported.
>> >       
>> >            clear text password is not supported. TODO: contradiction in
>> >            the
>> > 
>> > previous sentence
>> 
>> In the replication mode or master/slave mode, trust, clear text
>> password, and pam methods are supported. From pgpool-II 3.0 md5 is
>> also supported.
>> 
>> > <code>JOIN</code>s like above will be executed on each backend, and
>> > then merged with the results returned by each backend. Views and Rules
>> > that join across the nodes cannot be created.
>> > This VIEW is registered in the pgpool_catalog.dist_def table. A col_name
>> > and a dist_def_func will have to be registered too. These are used when
>> > an insert is
>> > performed on the view.
>> > </p> TODO: I don't really get this one
>> > 
>> > <code>JOIN</code>s like above will be executed on each backend, and
>> > then merged with the results returned by each backend.
>> 
>> I assume you get this paragraph.
>> 
>> > Views and Rules
>> > that join across the nodes cannot be created.
>> > However, to JOIN tables that access data only in the same node, a VIEW
>> > can be made.
>> 
>> I think this one just says unlike explicit JOINs, the results of the
>> VIEWs are not automatically merged.
>> 
>> > The column names and types are needed when a query is analyzed in
>> > parallel mode.
>> > Therefore, when an expression or a function is used in the TARGETLIST of
>> > a subquery, the alias and type (through a cast) are needed. Please note
>> > that if no cast is provided in an expression or a function, the text
>> > type will be chosen as a default. For count(), bigint type is assumed,
>> > and for sum(), numeric. For min()/max(), if the argument is a date type,
>> > returned datatype is date,
>> > else, it is assumed numeric. avg() is processed as sum/count.
>> > TODO : which one ? numeric or bigint ?
>> 
>> This one says "avg()" is rewritten to "sum()/count()". Thus the
>> returned data type of "sum()/count()" is determined by PostgreSQL.
>> --
> 
> 
> Thanks.
> 
> I've corrected the last TODOs, there are no longer any in the document. As far 
> as I'm concerned, this version is OK :)

Thanks. Guillaume, could you please commit this if you are
comfortable? Because you have done extensive proof reading.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp