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 по дате отправления: