Re: Improve GetConfigOptionValues function
От | Nitin Jadhav |
---|---|
Тема | Re: Improve GetConfigOptionValues function |
Дата | |
Msg-id | CAMm1aWZRHQN68QZ9Jrs3X0ATrUHbjD+Cd_ONk6QhxbwmAEO9mg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve GetConfigOptionValues function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Improve GetConfigOptionValues function
|
Список | 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
В списке pgsql-hackers по дате отправления: