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 →
-
Allow "SET list_guc TO NULL" to specify setting the GUC to empty.
- ff4597acd4c3 19 (unreleased) landed
Attachments
- v5-allow-SET-to-an-empty-list.patch (text/x-diff) patch v5
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