From: Tom Lane <tgl@sss.pgh.pa.us>
To: Florin Irion <irionr@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Shinya11.Kato@oss.nttdata.com
Cc: masao.fujii@oss.nttdata.com
Cc: bharath.rupireddyforpostgres@gmail.com
Cc: daniel@yesql.se
Cc: pgsql-hackers@postgresql.org
Subject: Re: Emit a warning if the extension's GUC is set incorrectly
Date: Fri, 18 Feb 2022 17:18:21 -0500
Message-ID: <4160911.1645222701@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+HEvJC7xADXaz2PRc5pPj3psNT-==aQ0HxDbvqw8OgfzUa1_Q@mail.gmail.com>
References: <9f5e96ca44891915f1d2736bea9fdf45@oss.nttdata.com>
<83b33009-3a1b-9230-8f07-2115763c1853@enterprisedb.com>
<c5660e836dd511549810fd35b12edc3c@oss.nttdata.com>
<20211221.100834.1297468238807011575.horikyota.ntt@gmail.com>
<57009.1640107405@sss.pgh.pa.us>
<116024.1640111629@sss.pgh.pa.us>
<1640909.1640638123@sss.pgh.pa.us>
<1902182.1640711215@sss.pgh.pa.us>
<CA+HEvJC7xADXaz2PRc5pPj3psNT-==aQ0HxDbvqw8OgfzUa1_Q@mail.gmail.com>
Florin Irion <irionr@gmail.com> writes:
> Il giorno ven 18 feb 2022 alle ore 10:58 Tom Lane <tgl@sss.pgh.pa.us> ha
> scritto:
>> Here's a delta patch (meant to be applied after reverting cab5b9ab2)
>> that does things like that. It fixes the parallel-mode problem ...
>> so do we want to tighten things up this much?
> Thank you for taking care of the bug I introduced with 75d22069e,
> I didn't notice this thread until now.
Yeah, this thread kinda disappeared under the rug during the Christmas
holidays, but we need to decide whether we want to push forward or
leave things at the status quo.
> For what it's worth, I agree with throwing an ERROR if the placeholder is
> unrecognized. Initially, I didn't want to change too much the liberty of
> setting any placeholder, but mainly to not go unnoticed.
I also think that this is probably a good change to make.
One situation where somebody would be unhappy is if they're using GUC
variables as plain custom variables despite them being within the
namespace of an extension they're using. But that seems to me to be
(a) far-fetched and (b) mighty dangerous, since some new version of the
extension might suddenly start reacting to those variables in ways you
presumably didn't expect.
Perhaps a more plausible use-case is "I need to work with both versions
X and Y of extension E, and Y has setting e.foo while X doesn't --- but
I can just set e.foo unconditionally since X will ignore it". With this
patch, that could still work, but you'd have to be certain to apply the
setting before loading E.
I don't really see any other use-cases favoring the current behavior.
On balance, eliminating possible mistakes seems like enough of a
benefit to justify disallowing these cases.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, irionr@gmail.com, peter.eisentraut@enterprisedb.com, horikyota.ntt@gmail.com, Shinya11.Kato@oss.nttdata.com, masao.fujii@oss.nttdata.com, bharath.rupireddyforpostgres@gmail.com, daniel@yesql.se
Subject: Re: Emit a warning if the extension's GUC is set incorrectly
In-Reply-To: <4160911.1645222701@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox