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