On Tue, Feb 17, 2026 at 1:37 AM Álvaro Herrera <[email protected]> wrote:
> On 2026-Feb-16, Andres Freund wrote:
>
> > could be
> >
> > { oid => '3786', descr => 'set up a logical replication slot',
> > proname => 'pg_create_logical_replication_slot', provolatile => 'v',
> > proparallel => 'u',
> > proargs => [
> > {type => 'name', name => 'slot_name'},
> > {type => 'name', name => 'plugin'},
> > {type => 'bool', name => 'temporary', default => 'false'},
> > {type => 'bool', name => 'twophase', default => 'false'},
> > {type => 'bool', name => 'failover', default => 'false'},
> > ],
> > prorettype => [
> > {type => 'name', name => 'slot_name'},
> > {type => 'pg_lsn', name => 'lsn'},
> > ]
> > }
>
> This is pretty much the sort of thing I was imagining when I read
> Corey's argumentation. +1 for something along these lines.
I like this a lot too, but I'm noticing that with each iteration we're
getting closer to re-inventing SQL. Would it make sense in the long run to
have a mode on the CREATE FUNCTION command that cues initdb to create the
minimal function skeleton with prescribed oid on the first pass, but then
stores the defer-able parts (if any) for a later pass, perhaps in parallel?
Then we wouldn't have to worry about how to model all future additions to
CREATE FUNCTION, and instead focus on what parts of creating the function
need to be in the bootstrap pass.
