EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,

rather than executing the INTO clause with non-plpgsql semantics
as it was doing for the last few weeks/months.  This keeps our options
open for making it do the right plpgsql-ish thing in future without
creating a backwards compatibility problem.  There is no loss of
functionality since people can get the same behavior with CREATE TABLE AS.

diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 0e570ed92c5202d2586271c1aea5db6939e3bf58..767dd68347d07430d76081a4f657e6a998f73f86 100644 (file)
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -1993,7 +1993,6 @@ exec_stmt_dynexecute(PLpgSQL_execstate * estate,
        switch (exec_res)
        {
                case SPI_OK_SELECT:
-               case SPI_OK_SELINTO:
                case SPI_OK_INSERT:
                case SPI_OK_UPDATE:
                case SPI_OK_DELETE:
@@ -2006,6 +2005,16 @@ exec_stmt_dynexecute(PLpgSQL_execstate * estate,
                         */
                        break;
 
+               case SPI_OK_SELINTO:
+                       /*
+                        * Disallow this for now, because its behavior is not consistent
+                        * with SELECT INTO in a normal plpgsql context.  We need to
+                        * reimplement EXECUTE to parse the string as a plpgsql command,
+                        * not just feed it to SPI_exec.
+                        */
+                       elog(ERROR, "EXECUTE of SELECT ... INTO is not implemented yet");
+                       break;
+
                default:
                        elog(ERROR, "unexpected error %d in EXECUTE of query '%s'",
                                 exec_res, querystr);