Re: "unix_socket_directories" should be GUC_LIST_INPUT?
От | Ian Lawrence Barwick |
---|---|
Тема | Re: "unix_socket_directories" should be GUC_LIST_INPUT? |
Дата | |
Msg-id | CAB8KJ=jCH+K4t-C+GQTn_e+4Eg1DaGZTAWY4wnPcdzuWz+GYyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: "unix_socket_directories" should be GUC_LIST_INPUT? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "unix_socket_directories" should be GUC_LIST_INPUT?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: