On Mon, Aug 20, 2012 at 9:59 AM, Andreas Kretschmer <akretschmer@xxxxxxxxxxxxx> wrote: > salah jubeh <s_jubeh@xxxxxxxxx> wrote: > >> Hello Andreas, >> >> Thanks for the reply, The example I have posted is very simple and you are >> right it is very similar to select max (id) from table_that_does_not_exist; But >> there are more here, for example imagine I have something like >> >> CREATE VIEW a4 as select .... from a3(), .... ; >> >> In my opinion, this might leads to many problems such as > > Again, the functions doesn't depend on the table, other example: > > test=# select * from foo; > id | val > ----+----- > 1 | 100 > 2 | 200 > 3 | 300 > (3 rows) > > Time: 0,235 ms > test=*# create or replace function fail(int) returns int as $$declare r > int; begin execute 'select val from foo where id = ' || $1 || ';' into > r; return r;end; $$language plpgsql; > CREATE FUNCTION > Time: 0,547 ms > test=*# select * from fail(1); > fail > ------ > 100 > (1 row) > > Time: 0,473 ms > test=*# drop table foo; > DROP TABLE > Time: 0,387 ms > test=*# select * from fail(1); > ERROR: relation "foo" does not exist > LINE 1: select val from foo where id = 1; > ^ > QUERY: select val from foo where id = 1; > CONTEXT: PL/pgSQL function "fail" line 1 at EXECUTE statement > > > In this case, the query inside the function is a dynamic query. So what? Another aspect that makes inside the body function dependency checking really difficult is search_path dependencies. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general