From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <chap@anastigmatix.net>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Loose ends after CVE-2020-14350 (extension installation hazards)
Date: Fri, 14 Aug 2020 15:38:12 -0400
Message-ID: <655710.1597433892@sss.pgh.pa.us> (raw)
In-Reply-To: <5F36E107.50907@anastigmatix.net>
References: <653936.1597431032@sss.pgh.pa.us>
<5F36E107.50907@anastigmatix.net>
Chapman Flack <chap@anastigmatix.net> writes:
> On 08/14/20 14:50, Tom Lane wrote:
>> SAVEPOINT s1;
>> SET LOCAL search_path = pg_catalog, pg_temp;
>> ... protected code here ...
>> RELEASE SAVEPOINT s1;
>> but this does not work because SET LOCAL persists to the end of the
>> outer transaction. Maybe we could invent a variant that only lasts
>> for the current subtransaction.
> This reminds me of the way the SQL standard overloads WITH to supply
> lexically-scoped settings of things, as well as CTEs, mentioned a while
> back. [1]
> Would this provide additional incentive to implement that syntax,
> generalized to support arbitrary GUCs and not just the handful of
> specific settings the standard uses it for?
Hmm. I see a few things not to like about that:
(1) It's hard to see how the WITH approach could work for GUCs
that need to take effect during raw parsing, such as the much-detested
standard_conforming_strings. Ideally we'd not have any such GUCs, for
the reasons explained at the top of gram.y, but I dunno that we'll ever
get there.
(2) We only have WITH for DML (SELECT/INSERT/UPDATE/DELETE), not utility
commands. Maybe that's enough for the cases at hand. Or maybe we'd be
willing to do whatever's needful to handle WITH attached to a utility
command, but that could be a pretty large addition of work.
(3) If the SQL syntax is really just "WITH variable value [, ...]"
then I'm afraid we're going to have a lot of parse-ambiguity problems
with wedging full SET syntax into that. The ability for the righthand
side to be a comma-separated list is certainly going to go out the
window, and we have various other special cases like "SET TIME ZONE"
that aren't going to work. Again, maybe we don't need a full solution,
but it seems like it's gonna be a kluge.
(4) You'd need to repeat the WITH for each SQL command, IIUC. Could
get tedious.
So maybe this is worth doing just for more standards compliance, but
it doesn't really seem like a nicer solution than subtransaction-
scoped SET.
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, chap@anastigmatix.net, pgsql-hackers@lists.postgresql.org
Subject: Re: Loose ends after CVE-2020-14350 (extension installation hazards)
In-Reply-To: <655710.1597433892@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