> 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.
