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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
