Fujii Masao <masao.fujii@gmail.com> writes:
>>> Even with this patch, an empty string set via SET is still quoted. For example:
>>>
>>> =# SET local_preload_libraries TO '';
>>> SET
>>> =# SHOW local_preload_libraries ;
>>> local_preload_libraries
>>> -------------------------
>>> ""
>>> (1 row)
>>>
>>> Is this behavior acceptable? I was thinking that an empty string should not
>>> be quoted, regardless of whether it's set by ALTER SYSTEM SET or SET.
> BTW, regarding the behavior change, I believe that users likely expect
> the parameter to be reset when specifying an empty string, rather than
> being set to "". So the proposed change seems reasonable. However,
> the current behavior has existed for a long time, and I haven’t seen
> any complaints about it.
I think this is largely based on confusion. In the above example,
local_preload_libraries is being set to a list containing a single
entry that is an empty string, and the output of SHOW is a fully
accurate depiction of that state. It is *not* being set to an
empty list --- we actually don't have any syntax that would permit
doing so in SET. For comparison, there is a big difference between
SET local_preload_libraries = a, b;
SET local_preload_libraries = 'a, b';
In the latter case you get a single list entry containing the
string "a, b". We do not try to parse that into multiple entries,
and by the same token parsing an empty string into an empty list
would be the Wrong Thing.
We might want to start resolving this by inventing a syntax for
setting a list GUC to an empty list. I'm not very sure what that
should look like, except that it mustn't be SET ... TO ''.
I'm not certain whether config-file parsing or ALTER SYSTEM
would need any code changes once we resolve the ambiguity in SET.
The config-file syntax is different and doesn't have this problem
of not being able to represent an empty list.
(Also, "let's unify the list-GUC syntax between config file and SET"
seems like a non-starter. It'd be better no doubt if they hadn't
diverged, but at this point we'd break far more than we fix if
we change either one.)
regards, tom lane
