Re: Improve GetConfigOptionValues function

Nitin Jadhav <nitinjadhavpostgres@gmail.com>

From: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-27T13:16:43Z
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@sss.pgh.pa.us> wrote:
>
> Nitin Jadhav <nitinjadhavpostgres@gmail.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