Re: Include RELKIND_TOASTVALUE in get_relkind_objtype

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Include RELKIND_TOASTVALUE in get_relkind_objtype
Дата
Msg-id 20191010050703.GF1852@paquier.xyz
обсуждение исходный текст
Ответ на Re: Include RELKIND_TOASTVALUE in get_relkind_objtype  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Include RELKIND_TOASTVALUE in get_relkind_objtype  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: btendouan
Дата:
Сообщение: Re: pgbench - extend initialization phase control
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum