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