Re: Intended behaviour of SET search_path with SQL functions?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Intended behaviour of SET search_path with SQL functions?
Date: 2008-03-06 18:09:32
Message-ID: 19078.1204826972@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Huxton <dev(at)archonet(dot)com> writes:
> => CREATE OR REPLACE FUNCTION func_b() RETURNS SETOF int AS $$
> SELECT id FROM table_a;
> $$ LANGUAGE sql SET search_path = alpha;
> ERROR: relation "table_a" does not exist

Hmmm, I'll bet the validator forgets to apply the parameter modification.

In plpgsql we had to dumb down the validator to do only a bare
syntax check and not any semantic validation. Perhaps SQL function
validation should act the same? You can certainly think of plenty
of other reasons why a full semantics check might fail at function
definition time.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2008-03-06 18:10:30 Re: Behaviour of to_tsquery(stopwords only)
Previous Message Tom Lane 2008-03-06 18:00:25 Re: 8.3.0 Core with concurrent vacuum fulls