Re: [PATCH] Fix ALTER SYSTEM empty string bug for GUC_LIST_QUOTE parameters

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Fujii Masao <masao.fujii@gmail.com>, Andrei Klychkov <andrew.a.klychkov@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-09-05T21:06:17Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Allow "SET list_guc TO NULL" to specify setting the GUC to empty.

Attachments

Jim Jones <jim.jones@uni-muenster.de> writes:
> On 04.09.25 23:52, Tom Lane wrote:
>> I'm not entirely sure if this is the way to go, or if we want to
>> adopt some other solution that doesn't involve forbidding empty
>> list elements.  I suspect that anything else we come up with would
>> be less intuitive than letting SET list_var = '' do the job;
>> but maybe I just lack imagination today.

> The ambiguity between an empty list and an empty element has always
> existed in list-valued GUCs. This patch resolves the issue by
> disallowing empty elements, thereby making '' an unambiguous
> representation of an empty list. Personally, I find SET var TO NULL (or
> perhaps a keyword like EMPTY or NONE) a more palatable syntax for
> expressing empty lists in this case. However, I’m not sure the
> additional complexity and compatibility implications would justify such
> a change.

Since you expressed interest, I made a draft patch that does it like
that.  Unsurprisingly, it has to touch mostly the same places that
the v3 patch did, plus the grammar.  Still ends up a bit shorter
though.

I remain unsure which way I like better.  The NULL approach has the
advantage of not foreclosing use of empty-string list elements, which
we might want someday even if there's no obvious value today.  (And
for the same reason, it's less of a behavioral change.)  But it still
feels a bit less intuitive to me.  It might flow better with some
other keyword --- but we have to use a fully-reserved keyword, and we
are surely not going to make a new one of those just for this purpose,
and NULL is the only existing one that's even slightly on-point.

			regards, tom lane