On 31.10.2010 21:42, Dimitri Fontaine wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.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@.' || 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.
Just do "SET search_path=@extschema@" at the beginning of the install
script, just like we have "SET search_path=public" there now.
> 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@.=) bar
>
> Also, those examples are plpgsql but extensions are free to depend on
> plperl or plpython, or even some pljs or plscheme out there.
Well, in case of functions you can always do "CREATE FUNCTION ... AS $$
... $$ SET search_path=@extschema".
"ALTER ... SET SCHEMA" wouldn't do anything for SQL statements embedded
in plperl or plpython anyway.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com