Re: Possible regression setting GUCs on \connect

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible regression setting GUCs on \connect
Date: 2023-05-17 11:56:54
Message-ID: CAPpHfduokYDndx=vpDaiCE1vbHt=dm4OwSNCmaGG6t58EtfP2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Amit.

On Wed, May 17, 2023 at 9:47 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I see there are mainly three concerns (a) Avoid adding the new option
> USER SET, (b) The behavior of this feature varies from the precedents
> set by a0ffa885e and 13d838815, (c) As per discussion, not following
> 13d838815 could lead to a similar security hole in this feature.
>
> Now, I don't know whether Tom and or Nathan share your viewpoint and
> feel that nothing should be done. It would have been better if such a
> discussion happens during development but I can understand that mostly
> the other senior people are sometimes busy enough to pay attention to
> all the work going on. I see that when Alexander proposed this new
> option and behavior in the original thread [1], there were no
> objections, so the commit followed the normal community rules but we
> have seen various times that post-commit reviews also lead to changing
> or reverting the feature.
>
> I see that you seem to think it would be over-engineering to follow
> the suggestions shared here but without the patch or some further
> discussion, it won't be easy to conclude that.
>
> Tom/Nathan, do you have any further suggestions here?

I think the main question regarding the USER SET option is its
contradiction with Tom's plans to track the setter role OID per
setting. If we do track role OID then it makes USER SET both
unnecessary for users and undesired complications for development.
However, I've expressed my doubts about the tracking setter role OID
[1], [2]. I think these plans look good in the big picture, but
implementation will have so many caveats that implementation will
stall for a long time (probably forever). If we accept this view, the
USER SET option might seem a good practical solution for real-world
issues.

I think if we would elaborate more on tracking setter role OID, come
to at least sketchy design then it could be easily to come to an
agreement on future directions.

Links.
1. https://www.postgresql.org/message-id/CAPpHfdsy-jxhgR0bWk1Fv63c6txwMAkzxFMGMf29jqa9uU_CdQ%40mail.gmail.com
2. https://www.postgresql.org/message-id/CAPpHfdu6roOVEUsV9TWNdQ%3DTZCrNEEwJM62EQiKULUyjpERhtg%40mail.gmail.com

------
Regards,
Alexander Korotkov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-05-17 12:08:36 Re: Possible regression setting GUCs on \connect
Previous Message Daniel Gustafsson 2023-05-17 11:49:54 Re: pipe_read_line for reading arbitrary strings