| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH] Add pg_get_subscription_ddl() function |
| Date: | 2025-11-13 08:20:41 |
| Message-ID: | 202511130814.dv55zvh7zqe5@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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".
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Álvaro Herrera | 2025-11-13 08:13:40 | Re: Few untranslated error messages in OAuth |