From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER OBJECT any_name SET SCHEMA name |
Date: | 2010-10-31 22:02:55 |
Message-ID: | AANLkTimkuTX9pgoKFm75_XxG4xO51qz=LTJOQgXZxb50@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 31, 2010 at 5:46 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Just do "SET search_path=(at)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=(at)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2010-10-31 22:04:24 | Re: type info refactoring |
Previous Message | Peter Eisentraut | 2010-10-31 22:01:11 | Re: type info refactoring |