From: | Erwin Brandstetter <brsaweda(at)gmail(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | "SET search_path" clause ignored during function creation |
Date: | 2010-05-06 14:26:06 |
Message-ID: | 9a425d37-9332-4c3b-80fd-683a7fdb6b0a@p2g2000yqh.googlegroups.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
As discussed in irc://freenode/postgresql (2010-05-06 16:20)
Function bodies are checked using the _current_ search_path instead of
the search_path supplied by the "SET search_path" clause.
This leads to wrong error messages during creation.
On the other hand it can make a function body pass the check, even
though it will raise an error is use.
Proposed solution: Function bodies should be checked with the
search_path provided by "SET search_path" an _not_ with the current
search path at the time pof creation.
Ho to reproduce the bug:
/*
event=# show search_path;
search_path
-------------
public
*/
CREATE SCHEMA foo;
CREATE TABLE foo.adr
( adr_id integer primary key,
note text);
INSERT INTO foo.adr VALUES (1, 'note from table foo.adr');
CREATE FUNCTION f_test()
RETURNS text AS
'SELECT note FROM adr where adr_id = 1'
LANGUAGE 'sql'
SET search_path=foo;
-- ERROR: relation "adr" does not exist
-- LINE 3: 'SELECT note FROM adr where adr_id = 1'
-- Function body is falsely checked with "search_path=
public" (current search_path) instead of "search_path=foo" AS it
should be!
-- If I disable check_function_bodies before creation, creation works
and the function call works and returns the value of foo.adr
correctly.
SET check_function_bodies=false;
Regards
Erwin Brandstetter
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-05-06 15:05:26 | Re: BUG #5451: pg_restore doesn't close input .tar archive |
Previous Message | Pavel Golub | 2010-05-06 12:14:57 | BUG #5451: pg_restore doesn't close input .tar archive |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-05-06 14:27:09 | Re: possible memory leak with SRFs |
Previous Message | Simon Riggs | 2010-05-06 14:24:54 | Re: max_standby_delay considered harmful |