Re: "unix_socket_directories" should be GUC_LIST_INPUT?

From: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:13:56
Message-ID: CAB8KJ=jCH+K4t-C+GQTn_e+4Eg1DaGZTAWY4wnPcdzuWz+GYyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2020年10月23日(金) 12:56 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > I'll look again at that in the next couple of days and double-check
> > the relevant areas of the code, just in case. It is Friday afternoon
> > here, and I suspect that my mind is missing something obvious.
>
> Indeed. The patch fails to update pg_dump.c's
> variable_is_guc_list_quote(), which exposes the real problem here:
> changing an existing variable's GUC_LIST_QUOTE property is an API break.

Aha, noted.

> Getting pg_dump to cope with such a situation would be a research project.
> The easy part of it would be to make variable_is_guc_list_quote() be
> version-aware; the hard part would be figuring out what to emit so that
> SET clauses will load correctly regardless of which PG version they will
> be loaded into.
>
> I suspect you're right that this variable should have been marked as a
> list to start with, but I'm afraid changing it at this point would be
> way more trouble than it's worth.

The use-case is admittedly extremely marginal, and presumably hasn't attracted
any other reports until now. I only noticed as I was poking around in
the area and
it looked inconsistent.

How about adding a comment along the lines of

/*
* GUC_LIST_INPUT not set here as the use-case is marginal and modifying it
* would require an API change.
*/

to clarify why it's like that and prevent someone else trying to "fix"
the same issue
in a few year's time?

Regards

Ian Barwick

--
EnterpriseDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2020-10-23 04:21:11 Re: new heapcheck contrib module
Previous Message Craig Ringer 2020-10-23 04:06:50 Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module