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
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo