Re: BUG #1277: plpgsql EXECUTE bug in beta3 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #1277: plpgsql EXECUTE bug in beta3
Date
Msg-id 366.1096909353@sss.pgh.pa.us
Whole thread Raw
In response to BUG #1277: plpgsql EXECUTE bug in beta3  ("PostgreSQL Bugs List" <pgsql-bugs@postgresql.org>)
List pgsql-bugs
"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> Under beta3, the following behaviour is observed:

> test=# create or replace function execute_sql(text) returns void AS $$begin
> execute $1; return; end; $$ language plpgsql;
> CREATE FUNCTION
> test=#
> test=# select execute_sql('create table a (i integer); insert into a(i)
> values(1);');
> ERROR:  relation "a" does not exist
> CONTEXT:  SQL query "create table a (i integer); insert into a(i)
> values(1);"
> PL/pgSQL function "execute_sql" line 1 at execute statement

This is happening because EXECUTE now parses and plans the whole string
in one go, so that it tries to plan the INSERT before the CREATE has
been carried out.  You would see the same behavior if you tried for
instance to execute those two commands as the body of an SQL function.
I am inclined to regard this as "not a bug", and tell you to execute the
two queries in separate EXECUTE commands.  I'm not sure it's worth the
substantial additional complexity in spi.c that would be needed to
preserve the old behavior --- especially when the documentation does not
suggest anywhere that you can use EXECUTE to execute more than one
command in the first place.

Anyone else have an opinion?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: bgwriter interfering with consistent view of system tables?
Next
From: Sean Chittenden
Date:
Subject: Re: bgwriter interfering with consistent view of system tables?