Re: Include RELKIND_TOASTVALUE in get_relkind_objtype
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Hsu, John" <hsuchen@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2019-10-10T05:07:03Z
Lists: pgsql-hackers
Attachments
- toast-acl-errors.patch (text/x-diff) patch
On Fri, Oct 04, 2019 at 05:55:40PM +0900, Michael Paquier wrote: > On Thu, Oct 03, 2019 at 09:52:34AM -0400, Tom Lane wrote: >> FWIW, I really dislike this patch, mainly because it is based on the >> assumption (as John said) that get_relkind_objtype is used only >> in aclcheck_error calls. However it's not obvious why that should >> be true, and there certainly is no documentation suggesting that >> it needs to be true. That's mainly because get_relkind_objtype has no >> documentation period, which if you ask me is flat out unacceptable >> for a globally-exposed function. (Same comment about its wrapper >> get_object_type.) > > Yes, I agree that the expectations that the caller of this function > can have are hard to guess. So we could tackle this occasion to add > more comments. I could try to come up with a better patch. Or > perhaps you have already your mind on it? Okay. Attached is what I was thinking about, with extra regression tests to cover the ground for toast tables and indexes that are able to reproduce the original failure, and more comments for the routines as they should be used only for ACL error messages. Any thoughts? -- Michael
Commits
-
Fix "unexpected relkind" error when denying permissions on toast tables.
- a30531c5c8a3 13.0 landed
- 791864193636 12.1 landed
- 2bfe015b5626 11.6 landed