Intended behaviour of SET search_path with SQL functions?
| От | Richard Huxton |
|---|---|
| Тема | Intended behaviour of SET search_path with SQL functions? |
| Дата | |
| Msg-id | 47D02728.2060503@archonet.com обсуждение исходный текст |
| Ответы |
Re: Intended behaviour of SET search_path with SQL functions?
|
| Список | pgsql-hackers |
=> SHOW search_path; search_path ------------- beta (1 row) => 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 CONTEXT: SQL function "func_b" => \d table_a Did not find any relation named "table_a". => \d alpha.table_a Table "alpha.table_a" Column | Type | Modifiers --------+---------+----------- id | integer | If I temporarily create a beta.table_a then I get to create the function and afterwards it does the right thing. It also works fine with a pl/pgsql function - presumably it's all down to context on the initial parse. I can't think of a way to exploit this maliciously, or do anything other than cause a little confusion, but I'm not sure it's intentional. -- Richard Huxton Archonet Ltd
В списке pgsql-hackers по дате отправления: