Re: [PATCH] Add pg_get_subscription_ddl() function
| От | Álvaro Herrera |
|---|---|
| Тема | Re: [PATCH] Add pg_get_subscription_ddl() function |
| Дата | |
| Msg-id | 202511130814.dv55zvh7zqe5@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add pg_get_subscription_ddl() function (Peter Smith <smithpb2250@gmail.com>) |
| Список | pgsql-hackers |
On 2025-Nov-13, Peter Smith wrote: > 1. Question - is it deliberate to *always* return DLL with every > possible option assigned, even if those are just the option default > values? e.g. For something like the CREATE PUBLICATION command the > string returned could be only half the size if it accounts for > default. Yeah, I was asking myself the same. I think we definitely want options to be printed when there are GUCs that can affect the outcome (e.g., something that is considered default in this server but not on a differently- configured one would give different results). But for those that are just hardcoded defaults, omitting them would make sense. > 2. I was also wondering if it was really necessary to have so many > appendStringInfoString() calls to reconstruct the command. There are a couple of these patches that have an auxiliary pretty-printing helper function to add newline-tabs instead of individual spaces. I think that wouldn't work as nicely if you tried to condense the printing in the way you suggest. On the other hand, if you have a long format string, it's harder to visually match each specifier to its corresponding argument. If this was performance-critical code I would agree to use denser code and avoid function calls, but for this usage I don't think we care much. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ Al principio era UNIX, y UNIX habló y dijo: "Hello world\n". No dijo "Hello New Jersey\n", ni "Hello USA\n".
В списке pgsql-hackers по дате отправления: