Re: ALTER OBJECT any_name SET SCHEMA name
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-10-31T22:02:55Z
Lists: 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