Re: "unix_socket_directories" should be GUC_LIST_INPUT? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "unix_socket_directories" should be GUC_LIST_INPUT?
Date
Msg-id 123121.1603428597@sss.pgh.pa.us
Whole thread Raw
In response to Re: "unix_socket_directories" should be GUC_LIST_INPUT?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "unix_socket_directories" should be GUC_LIST_INPUT?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
I wrote:
>  * unix_socket_directories should have been marked GUC_LIST_INPUT |
>  * GUC_LIST_QUOTE, but it's too late to change it without creating
>  * big compatibility problems for pg_dump.

Although ... just to argue against myself for a moment, how likely
is it that pg_dump is going to be faced with the need to dump a
value for unix_socket_directories?

Generally speaking, the value of that variable is sufficiently
embedded into builds that you aren't going to mess with it.
It's close to being part of the FE/BE protocol, since whatever
build of libpq you use is going to know about one or another
of those directories, and the only reason to have more than one
is if you have other clients that hard-wire some other directory.

Even ignoring that point, since it's PGC_POSTMASTER, you certainly
aren't going to have cases like function SET clauses or ALTER
USER/DATABASE SET commands to dump.  Unless pg_dumpall worries
about postgresql.auto.conf, which I don't think it does, the actual
use-case for it to dump a value for unix_socket_directories is nil
--- and even having the variable's value set in postgresql.auto.conf
seems like a seriously niche use-case.

So maybe we could get away with just changing it.  It'd be good to
verify though that this doesn't break existing string values for
the variable, assuming they contain no unlikely characters that'd
need quoting.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: Amit Kapila
Date:
Subject: Re: Track statistics for streaming of in-progress transactions