From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hsu, John" <hsuchen(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: Include RELKIND_TOASTVALUE in get_relkind_objtype |
Date: | 2019-10-10 05:07:03 |
Message-ID: | 20191010050703.GF1852@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
toast-acl-errors.patch | text/x-diff | 3.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2019-10-10 05:19:46 | Re: [HACKERS] Block level parallel vacuum |
Previous Message | btendouan | 2019-10-10 04:30:54 | Re: pgbench - extend initialization phase control |