Re: ALTER OBJECT any_name SET SCHEMA name
От | Dimitri Fontaine |
---|---|
Тема | Re: ALTER OBJECT any_name SET SCHEMA name |
Дата | |
Msg-id | m2vd4i9mj6.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: ALTER OBJECT any_name SET SCHEMA name (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: ALTER OBJECT any_name SET SCHEMA name
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > If I understand that correctly, the idea is that p_fun holds the name of a > function that's in the same schema as the extension? You would write that as > > v_sql := 'SELECT * FROM @extschema@.' || p_fun || '()'; Fair enough. Now what about the citext example, where IIRC the failure is not on function names but operators and opclass not found, etc. Forcing extension's author to get to always use the following notation seems to me like pushing it: - WHERE foo = bar + WHERE foo operator(@extschema@.=) bar Also, those examples are plpgsql but extensions are free to depend on plperl or plpython, or even some pljs or plscheme out there. The alternative is to give DBAs the tools to move their local extensions in some schema that is part of their edited search_path, should they remove public from there. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: