> 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 _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
