On Tue, Apr 30, 2013 at 12:46 AM, Noah Misch <noah@leadboat.com> wrote:
> 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.
Right. The "sql" procedural language was what I had in mind.
> Those existing functions give a mostly-SnapshotNow picture of their objects,
> but an sql-language implementation would give a normally-snapshotted picture.
I assume "normally" is better than "mostly"?
> 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.
I didn't think there would be any reason to migrate the existing
functions from C to SQL, but this snapshot problem seems like a good
motive to do it. If they would all be written in SQL, the snapshot
problem would be solved, right?
> 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.
What do you mean with "infrastructure"? Isn't it as simple as CREATE
OR REPLACE FUNCTION? As long as the interface the pg_get_*def
functions don't change, I cannot see how simply replacing the existing
functions in a minor release upgrade could do any harm.