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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: type info refactoring