On Tue, Apr 30, 2013 at 12:46 AM, Noah Misch <n...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
