Re: Possible regression setting GUCs on \connect - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Possible regression setting GUCs on \connect
Date
Msg-id CAPpHfduokYDndx=vpDaiCE1vbHt=dm4OwSNCmaGG6t58EtfP2g@mail.gmail.com
Whole thread Raw
In response to Re: Possible regression setting GUCs on \connect  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hi, Amit.

On Wed, May 17, 2023 at 9:47 AM Amit Kapila <amit.kapila16@gmail.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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pipe_read_line for reading arbitrary strings
Next
From: Tom Lane
Date:
Subject: Re: Possible regression setting GUCs on \connect