Re: sloppy back-patching of column-privilege leak

Stephen Frost wrote:

> > Besides the sloppiness of back-patching in
> > that one macro and nothing else, this is a huge fraction of the patch
> > that's just *gone* in the 9.0 and 9.1 branches, and there's not so
> > much as a hint about it in the commit message, which is pretty
> > astonishing to me.
> 
> Right, 9.0 and 9.1 don't have as detailed messages and so there wasn't
> as much to do in those older branches.  I was well aware of that and I
> could have sworn that I included something in the commit messages..
> Looks like I did, but not in a way which was as clear as it should have
> been.  Specifically, in those older branches, the commit message only
> talks about the functions which exist in those branches-
> BuildIndexValueDescription and ri_ReportViolation.  The commit messages
> for 9.2 and beyond also reference ExecBuildSlotValueDescription, which
> is what you're getting at.
> 
> In hindsight, I agree that doing just that wasn't sufficient and
> thinking on it now I realize that, while having different commit
> messages for each branch may make sense if you're only looking at that
> branch, it ends up being confusing for folks following the overall
> project as they likely look at just the subject of each commit and
> expect the contents for every branch to be the same.  To that point,
> I'll try to be clearer when there's a difference in commit message for
> each branch, or simply include everything for every branch in an
> identical commit message across all of them.

FWIW using different commit messages for different branches is a
mistake.  The implicit policy we have is that there is one message,
identical for all branches, that describe how the patch differs in each
branch whenever necessary.  Note that the git_changelog output that
Robert pasted is not verbatim from the tool; what it actually prints is
three separate entries, one for each different message you used, which
is not what is supposed to occur.

I say this policy is implicit because I don't recall it being spelled
out anywhere, but since it's embodied in git_changelog's working
principle it's important we stick to it.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services