On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >>> In short, it seems like this statement in the docs is correctly describing >>> our code's behavior, but said behavior is wrong and should be changed. >>> I'd propose fixing it like that in HEAD; I'm not sure if the back branches >>> should also be changed. > >> Sounds reasonable, but I don't see much advantage to changing it in >> the back-branches. > > Well, it's a SQL-compliance bug, and we often back-patch bug fixes. Personally, I'd be more inclined to view it as a definitional change. Maybe we picked the wrong definition before, but it's well-established behavior at this point. The SQL standard also says that identifiers are supposed to be folded to upper case, so I don't think the theory that every deviation from the standard should be fixed and back-patched holds a lot of water. > The argument for not back-patching a bug fix usually boils down to > fear of breaking existing applications, but it's hard to see how > removal of a permission check could break a working application --- > especially when the permission check is as hard to trigger as this one. > How many table owners ever revoke their own REFERENCES permission? Sure, but that argument cuts both ways. If nobody ever does that, who will be helped by back-patching this? I certainly agree that back-patching this change is pretty low risk. I just don't think it has any real benefits. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
