2020年10月23日(金) 12:56 Tom Lane <tgl@sss.pgh.pa.us>:
>
> Michael Paquier <michael@paquier.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
