Re: Include RELKIND_TOASTVALUE in get_relkind_objtype - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Include RELKIND_TOASTVALUE in get_relkind_objtype
Date
Msg-id 20191010050703.GF1852@paquier.xyz
Whole thread Raw
In response to Re: Include RELKIND_TOASTVALUE in get_relkind_objtype  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Include RELKIND_TOASTVALUE in get_relkind_objtype
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: btendouan
Date:
Subject: Re: pgbench - extend initialization phase control
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum