On Mon, Apr 29, 2013 at 10:16:22PM +0100, Joel Jacobson wrote:
> Existing:
>
> pg_get_constraintdef
> pg_get_indexdef
> pg_get_viewdef
> pg_get_triggerdef
> pg_get_functiondef
> pg_get_ruledef
>
> Missing:
>
> pg_get_ts_templatedef
> pg_get_ts_parserdef
> pg_get_ts_configdef
> pg_get_ts_dictdef
> pg_get_databasedef
> pg_get_namespacedef
> pg_get_languagedef
> pg_get_conversiondef
> pg_get_castdef
> pg_get_amprocdef
> pg_get_operatordef
> pg_get_amopdef
> pg_get_opfamilydef
> pg_get_opclassdef
> pg_get_tabledef
> pg_get_sequencedef
> pg_get_typedef
> pg_get_attrdef
>
> I'm planning to implement these. Is there any reason why the remaining
> functions cannot be written as SQL functions instead of C? The input data
> to the C-functions in pg_dump.c comes from pg_catalog anyway, so I thought
> it would be a lot easier just to construct the definitions in SQL where you
> have convenient access to the pg_catalog.
Note that while the sql procedural language is fair game, plpgsql currently is
not. We install it by default, but the DBA is free to drop it.
Those existing functions give a mostly-SnapshotNow picture of their objects,
but an sql-language implementation would give a normally-snapshotted picture.
That status quo is perhaps more an implementation accident than a designed
behavior. Before proliferating functions like this, we should pick a snapshot
policy and stick to it. See the block comment at the top of pg_dump.c.
Note also that minor releases can readily fix bugs in C-language functions,
but we have no infrastructure to update sql-language functions after initdb.
That flexibility is unfortunate to lose, particularly for something that
pg_dump depends on. Now, the right thing is probably to design a mechanism
for applying simple catalog updates in concert with a minor release. In the
mean time, its absence puts the sql PL at a nontrivial disadvantage here.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
