On Wed, Feb 20, 2019 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Joe Conway <mail@joeconway.com> writes:
> > On 2/20/19 11:10 AM, PG Bug reporting form wrote:
> >> But current behavior returns empty string instead of NULL (the initial
> >> value) after transaction is rolled back. When I restart session, NULL is
> >> returned again as it is expected.
>
> > This has been discussed before and dismissed:
> > https://www.postgresql.org/message-id/flat/56842412.5000005%40joeconway.com
> > Personally I agree it is a bug, but I am not sure you will get much
> > support for that position.
>
> The fact that we allow undeclared user-defined GUCs at all is a bug IMO.
> We need to find a way to replace that behavior with something whereby
> the name and type of a parameter are declared up-front before you can
> set it.
We should at least document the existing working-as-intended behavior
then. This, the linked thread, and Bug # 14877 are all caused by
insufficient documentation of the current behavior. Users should be
informed that as far as the GUC system is concerned NULL and the empty
string are equivalent and that resetting uses the empty string while
never being set returns NULL.
Its immaterial whether its existence is due to a bug that simply
became acceptable or was an otherwise retrospectively poor design
decision - at this point we have to live with it and should treat it
as a proper and supported feature, if only in its current form. At
least until someone feels strongly enough to deprecate it and put
something else more suitable in its place.
David J.