Hi Alvaro, Thanks for your input.
On Thu, Nov 6, 2025 at 9:18 PM Álvaro Herrera <[email protected]> wrote: > Hello Vaibhav, > > I wonder why is Subscription->publications a list of String rather than > a list of C strings. That's something you'd see in a Node structure, > but Subscription is not a node, so this seems wasteful and pointless. > I looked more into this and came to know that we can't make Subscription->publications a list of C strings because input publications list is also in the list of String from the parser: CreateSubscriptionStmt: CREATE SUBSCRIPTION name CONNECTION Sconst PUBLICATION name_list opt_definition { CreateSubscriptionStmt *n = makeNode(CreateSubscriptionStmt); n->subname = $3; n->conninfo = $5; n->publication = $7; n->options = $8; $$ = (Node *) n; }; name_list: name { $$ = list_make1(makeString($1)); } | name_list ',' name { $$ = lappend($1, makeString($3)); }; Oh, we also have textarray_to_strvaluelist() which is essentially > identical, but also static. If we're making one of them non-static, > then for sure let's remove the other one. But maybe what we really need > is a third one to use in ruleutils, and expose neither? (I think if we > get rid of the String around Subscription->publications, that's likely > what I'd do, since they'd be mostly trivial wrappers around > deconstruct_array_builtin.) > I think we really need a third one to use in ruleutils, and expose neither. Find the attached v3 patch which does the same.
v3-Add-pg_get_subscription_ddl-function.patch
Description: Binary data
