Re: ALTER OBJECT any_name SET SCHEMA name
От | Dimitri Fontaine |
---|---|
Тема | Re: ALTER OBJECT any_name SET SCHEMA name |
Дата | |
Msg-id | m28w1e827j.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: > Just do "SET search_path=@extschema@" at the beginning of the install > script, just like we have "SET search_path=public" there now. Well there's the installation itself then the "runtime", as you say later... > Well, in case of functions you can always do "CREATE FUNCTION ... AS $$ > ... $$ SET search_path=@extschema". Fair enough. > "ALTER ... SET SCHEMA" wouldn't do anything for SQL statements embedded in > plperl or plpython anyway. That's why I was thinking about adding the possibility to:- easily find your function's etc OID, that's already mainly done-be able to call/use those objects per OID Ok that sucks somehow. I think it's better than @extschema@ replacing in the extension's script parsing, though. Maybe we should just shut down this attempt at working on search_path and extensions together, again. I though it was a simple and good enough solution though, and that it would avoid the usual rat holes. But we're deep in them already. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: