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

Re: ALTER OBJECT any_name SET SCHEMA name

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 19:42:37
Message-ID: m2vd4i9mj6.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> If I understand that correctly, the idea is that p_fun holds the name of a
> function that's in the same schema as the extension? You would write that as
>
> v_sql := 'SELECT * FROM @extschema(at)(dot)' || p_fun || '()';

Fair enough. Now what about the citext example, where IIRC the failure
is not on function names but operators and opclass not found, etc.

Forcing extension's author to get to always use the following notation
seems to me like pushing it:

- WHERE foo = bar
+ WHERE foo operator(@extschema(at)(dot)=) bar

Also, those examples are plpgsql but extensions are free to depend on
plperl or plpython, or even some pljs or plscheme out there.


The alternative is to give DBAs the tools to move their local extensions
in some schema that is part of their edited search_path, should they
remove public from there.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-10-31 19:58:58
Subject: Re: [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
Previous:From: Dimitri FontaineDate: 2010-10-31 19:38:31
Subject: Re: ALTER OBJECT any_name SET SCHEMA name

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