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  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: type info refactoring
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: type info refactoring