Re: language handlers in public schema?
От | Andrew Dunstan |
---|---|
Тема | Re: language handlers in public schema? |
Дата | |
Msg-id | 42BF076A.7030708@dunslane.net обсуждение исходный текст |
Ответ на | Re: language handlers in public schema? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: language handlers in public schema?
|
Список | pgsql-hackers |
Tom Lane wrote: >regression=# explain analyze select * from pg_proc WHERE NOT proisagg AND (pronamespace != (select oid from pg_namespacewhere nspname = 'pg_catalog') >regression(# OR oid in (select lanplcallfoid from pg_language) OR oid in (select lanvalidator from pg_language)); > > > Yeah. I think we'd need to add "where langlcallfoid != 0" so we don't pick up the internal/C/sql handlers. However, on closer inspection it appears that doind all this in pg_dump would be lots more invasive than I first thought. An alternative would be to adopt AndrewSN's suggestion of an extra schema (or possibly two) created by initdb where we put extra stuff. That would mean a very simple addition to initdb.c and no changes to pg_dump, except ... >Next question is whether there are any other places that would be >affected besides createlang/droplang. I can't think of any offhand, >but ... > > > > me either, but I wonder if we should provide an option on pg_dump to restore function handlers found in public to whatever we decide about the above. thoughts? cheers andrew
В списке pgsql-hackers по дате отправления: