Re: ALTER OBJECT any_name SET SCHEMA name
От | Robert Haas |
---|---|
Тема | Re: ALTER OBJECT any_name SET SCHEMA name |
Дата | |
Msg-id | AANLkTimkuTX9pgoKFm75_XxG4xO51qz=LTJOQgXZxb50@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER OBJECT any_name SET SCHEMA name (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: ALTER OBJECT any_name SET SCHEMA name
|
Список | pgsql-hackers |
On Sun, Oct 31, 2010 at 5:46 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > 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. Yeah, I think that sucks a lot. I don't see what's wrong with Heikki's solution, actually. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: