From: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve GetConfigOptionValues function |
Date: | 2023-01-27 13:16:43 |
Message-ID: | CAMm1aWZRHQN68QZ9Jrs3X0ATrUHbjD+Cd_ONk6QhxbwmAEO9mg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Both of you are arguing as though GUC_NO_SHOW_ALL is a security
> property. It is not, or at least it's so trivially bypassable
> that it's useless to consider it one. All it is is a de-clutter
> mechanism.
Understood. If that is the case, then I am ok with the patch.
Thanks & Regards,
Nitin Jadhav
On Wed, Jan 25, 2023 at 9:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> writes:
> > I agree that the developer can use both GUC_NO_SHOW_ALL and
> > GUC_EXPLAIN knowingly or unknowingly for a single GUC. If used by
> > mistake then according to the existing code (without patch),
> > GUC_NO_SHOW_ALL takes higher precedence whether it is marked first or
> > last in the code. I am more convinced with this behaviour as I feel it
> > is safer than exposing the information which the developer might not
> > have intended.
>
> Both of you are arguing as though GUC_NO_SHOW_ALL is a security
> property. It is not, or at least it's so trivially bypassable
> that it's useless to consider it one. All it is is a de-clutter
> mechanism.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-01-27 13:31:32 | Re: improving user.c error messages |
Previous Message | Önder Kalacı | 2023-01-27 13:02:13 | Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher |