Re: "unix_socket_directories" should be GUC_LIST_INPUT?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "unix_socket_directories" should be GUC_LIST_INPUT?
Date: 2020-10-23 04:49:57
Message-ID: 123121.1603428597@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-10-23 04:54:27 Re: Track statistics for streaming of in-progress transactions
Previous Message Kyotaro Horiguchi 2020-10-23 04:46:11 Re: Get memory contexts of an arbitrary backend process