[COMMITTERS] pgsql: Still more tweaking of git_changelog.

2010-09-25 Thread Tom Lane
Still more tweaking of git_changelog. 1. Don't assume there's only one candidate match; check them all and use the one with the closest timestamp. Avoids funny output when someone makes several successive commits with the same log message, as certain people have been known to do. 2. When the sam

[COMMITTERS] pgsql: Fix some more bugs in git_changelog.

2010-09-25 Thread Tom Lane
Fix some more bugs in git_changelog. 1. Don't forget the last (oldest) commit on the oldest branch. 2. When considering which commit to print next, if two alternatives have the same "distortion" score (which is actually the normal case, since generally the "distortion" is 0), then choose the late

[COMMITTERS] pgsql: Fix man page markup for with multiple variants

2010-09-25 Thread Peter Eisentraut
Fix man page markup for with multiple variants Command synopses using with multiple variants previously used to break lines between variants. The new man page toolchain introduced in 9.0 makes a mess out of that, and that markup was probably wrong all along, because is supposed to break lines

[COMMITTERS] pgsql: Fix man page markup for with multiple variants

2010-09-25 Thread Peter Eisentraut
Fix man page markup for with multiple variants Command synopses using with multiple variants previously used to break lines between variants. The new man page toolchain introduced in 9.0 makes a mess out of that, and that markup was probably wrong all along, because is supposed to break lines

Re: [COMMITTERS] pgsql: Fix another join removal bug: the check on PlaceHolderVars was w

2010-09-25 Thread Tom Lane
David Fetter writes: > On Sat, Sep 25, 2010 at 11:04:28PM +, Tom Lane wrote: >> The previous coding would decide that join removal was unsafe upon >> finding a PlaceHolderVar that needed to be evaluated at the inner >> rel and then used above the join. However, this fails to cover the >> case

[COMMITTERS] pgsql: Minor improvements to git_changelog.

2010-09-25 Thread Tom Lane
Minor improvements to git_changelog. Avoid depending on Date::Calc, which isn't in a basic Perl installation, when we can equally well use Time::Local which is. Also fix the parsing of timestamps to take heed of the timezone. (It looks like cvs2git emitted all commit timestamps with zone GMT, so

Re: [COMMITTERS] pgsql: Fix another join removal bug: the check on PlaceHolderVars was w

2010-09-25 Thread David Fetter
On Sat, Sep 25, 2010 at 11:04:28PM +, Tom Lane wrote: > Fix another join removal bug: the check on PlaceHolderVars was > wrong. > > The previous coding would decide that join removal was unsafe upon > finding a PlaceHolderVar that needed to be evaluated at the inner > rel and then used above t

[COMMITTERS] pgsql: Rename git_topo_order -> git_changelog, per discussion.

2010-09-25 Thread Tom Lane
Rename git_topo_order -> git_changelog, per discussion. Branch -- master Details --- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=ce1dcd468f8a728398424296165a8d87eb36f0d8 Modified Files -- src/tools/RELEASE_CHANGES |6 +- src/tools/git_changelog | 16

Re: [COMMITTERS] pgsql: git_topo_order script, to match up commits across branches.

2010-09-25 Thread Tom Lane
Alvaro Herrera writes: > +1 to git_changelog anyway. That seems to be the consensus position, so done. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/

[COMMITTERS] pgsql: Fix another join removal bug: the check on PlaceHolderVars was w

2010-09-25 Thread Tom Lane
Fix another join removal bug: the check on PlaceHolderVars was wrong. The previous coding would decide that join removal was unsafe upon finding a PlaceHolderVar that needed to be evaluated at the inner rel and then used above the join. However, this fails to cover the case of PlaceHolderVars tha

[COMMITTERS] pgsql: Fix another join removal bug: the check on PlaceHolderVars was w

2010-09-25 Thread Tom Lane
Fix another join removal bug: the check on PlaceHolderVars was wrong. The previous coding would decide that join removal was unsafe upon finding a PlaceHolderVar that needed to be evaluated at the inner rel and then used above the join. However, this fails to cover the case of PlaceHolderVars tha

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr

[COMMITTERS] pgsql: Further fixes to the pg_get_expr() security fix in back branches

2010-09-25 Thread Tom Lane
Further fixes to the pg_get_expr() security fix in back branches. It now emerges that the JDBC driver expects to be able to use pg_get_expr() on an output of a sub-SELECT. So extend the check logic to be able to recurse into a sub-SELECT to see if the argument is ultimately coming from an appropr