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