Re: Possible regression setting GUCs on \connect

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Possible regression setting GUCs on \connect
Дата
Msg-id CA+TgmoZb=krMdR-G4qR3Vc3ezWPx73XSKntHw0Y9HFHFE0Fzrw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possible regression setting GUCs on \connect  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: Possible regression setting GUCs on \connect  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, May 17, 2023 at 1:31 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> I have carefully noted your concerns regarding the USER SET patch that
> I've committed.  It's clear that you have strong convictions about
> this, particularly in relation to your plan of storing the setter role
> OID in pg_db_role_setting.
>
> I want to take a moment to acknowledge the significance of your
> perspective and I respect that you have a different view on this
> matter.  Although I have not yet had the opportunity to see the
> feasibility of your approach, I am open to understanding it further.
>
> Anyway, I don't want to do anything counter-productive.  So, I've
> taken the decision to revert the USER SET patch for the time being.

This discussion made me go back and look at the commit in question. My
opinion is that the feature as it was committed is quite hard to
understand. The documentation for it said this: "Specifies that
variable should be set on behalf of ordinary role." But what does that
even mean? What's an "ordinary role"? What does "on behalf of" mean? I
think these are not terms we use elsewhere in the documentation, and I
think it wouldn't be easy for users to understand how to use the
feature properly. I'm not sure whether Tom's idea about what the
design should be is good or bad, but I think that whatever we end up
with, we should try to explain more clearly and thoroughly what
problem the feature solves and how it does so.

Imagine a paragraph someplace that says something like "You might want
to do X. But if you try to do it, you'll find that it doesn't work
because Y: [SQL example] We can work around this problem using the Z
feature. That lets us tell the system that it should Q, which fixes Y:
[SQL example].". It sounds like Tom might be proposing that we solve
this problem in some way that doesn't actually require any new SQL
syntax, and if we do that, then this might not be needed. But if we do
add syntax, then I think something like this would be really good to
have.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: "Tristan Partin"
Дата:
Сообщение: Meson build updates
Следующее
От: Nikita Malakhov
Дата:
Сообщение: Re: RFI: Extending the TOAST Pointer