Le 05/01/2011 10:45, Guillaume Lelarge a écrit : > Le 05/01/2011 10:38, Tatsuo Ishii a écrit : >>> 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. > > Sure, I take care of this. Thanks you both. >
Commited to the 3.0 branch (as it was a 3.0 document), and to HEAD (with the HEAD updates). Thanks, Marc. -- Guillaume http://www.postgresql.fr http://dalibo.com _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
