Skip site navigation (1) Skip section navigation (2)


From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, 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 21:46:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

> 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. 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.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2010-10-31 21:58:53
Subject: Re: type info refactoring
Previous:From: Andres FreundDate: 2010-10-31 21:41:50
Subject: [PATCH] Custom code int(32|64) => text conversions out of performance reasons

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group