From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sloppy back-patching of column-privilege leak |
Date: | 2015-02-09 21:16:31 |
Message-ID: | 20150209211631.GH3391@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-02-09 21:17:30 | Re: Odd behavior of updatable security barrier views on foreign tables |
Previous Message | Stephen Frost | 2015-02-09 21:10:51 | Re: more RLS oversights |