On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > tushar <tushar.ah...@enterprisedb.com> writes: >> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler; >> CREATE LANGUAGE > > pg_dump doesn't really support that scenario, and I don't feel any > great need to make it do so. Per the comment in dumpProcLang: > > * Try to find the support function(s). It is not an error if we > don't > * find them --- if the functions are in the pg_catalog schema, as is > * standard in 8.1 and up, then we won't have loaded them. (In this > case > * we will emit a parameterless CREATE LANGUAGE command, which will > * require PL template knowledge in the backend to reload.) > > So the assumption is basically that PLs that don't have pg_pltemplate > entries will not keep their support functions in pg_catalog.
Is this assumption, like, documented someplace? I tend to think it's pretty bad when users can execute SQL and then pg_dump doesn't work. I mean, if you play with the contents of pg_catalog, then I'm not sure how much we can guarantee, but I don't see how a user would know that there's anything wrong with Tushar's SQL command. I would be on board with the idea that you (or anyone, really) doesn't want to fix this because it's a fairly unimportant issue, but I balk at the notion that nothing is wrong here, because to me that looks busted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
