[Pgpool-hackers] First try at rephrasing the documentation

[Tatsuo Ishii]

>> 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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp