Обсуждение: Invalid statement name (null) in line ## - what am I doing wrong ?

Hi,

   I have a problem when upgrading from 8.2.4 to 8.3/8.4 using ecpg with a prepare statement:

EXEC SQL PREPARE execquery FROM :stmt; line = __LINE__;
EXEC SQL AT :_thisDbConn DECLARE execcurs CURSOR FOR execquery; line = __LINE__;
EXEC SQL AT :_thisDbConn OPEN execcurs; line = __LINE__;
EXEC SQL ALLOCATE DESCRIPTOR execdesc; line = __LINE__;

   I get an "SQL error: invalid statement name "(null)" on line ##" (3rd line above) on the OPEN cursor statement. I
havebeen digging a little in the ecpg output and noticed that the format of the ECPGprepare() function call has changed
between8.2.4 and 8.3++. Also the ecpg library has changed version libecpg.so.5 -> libecpg.so.6. 

   I am compiling my program on an (older) system with 8.2.4 installed and I need have my program running on a
productionsystem running 8.3.5 or higher. This seems to work fine, but for other reasons I wanted to upgrade my
"compilesystem" with 8.3.5 and this started to give me the error mentioned above. 

   An ldd on the program gives:

libecpg.so.6 => /usr/local/Packages/pgsql-8.3.5/lib/libecpg.so.6 (0xb7ed8000)
libpq.so.5 => /usr/local/Packages/pgsql-8.3.5/lib/libpq.so.5 (0xb7ebc000)

 which looks to be ok. (The 8.2.4 compiled program was using libecpg.so.5.)

   It seems to me that somehow the prepare statement (first line above) is compiled into a ECPGprepare() call with 5
parameters,but using a library function with only 3 parameters, even though it points to the libecpg.so.6, which
includescode having the 5 parameter ECPGprepare() function. 

   All PostgreSQL systems are natively installed from source on the various systems, i.e. compiled individually on each
system.All my systems are running Linux, but with different versions of Linux. 

   I have also tried the very newest version 8.4rc1, but with same result, the error above.

  Please help,

 Leif

can we see the original statement ?

can you combine the 2 statements to produce the necessary cursor

OPEN curs1 FOR EXECUTE 'SELECT * FROM ' || quote_ident($1);

http://www.postgresql.org/docs/8.1/interactive/plpgsql-cursors.html

takk
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung





> Date: Fri, 19 Jun 2009 03:08:35 +0200
> From: leif@crysberg.dk
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Invalid statement name (null) in line ## - what am I doing wrong ?
>
> Hi,
>
> I have a problem when upgrading from 8.2.4 to 8.3/8.4 using ecpg with a prepare statement:
>
> EXEC SQL PREPARE execquery FROM :stmt; line = __LINE__;
> EXEC SQL AT :_thisDbConn DECLARE execcurs CURSOR FOR execquery; line = __LINE__;
> EXEC SQL AT :_thisDbConn OPEN execcurs; line = __LINE__;
> EXEC SQL ALLOCATE DESCRIPTOR execdesc; line = __LINE__;
>
> I get an "SQL error: invalid statement name "(null)" on line ##" (3rd line above) on the OPEN cursor statement. I have been digging a little in the ecpg output and noticed that the format of the ECPGprepare() function call has changed between 8.2.4 and 8.3++. Also the ecpg library has changed version libecpg.so.5 -> libecpg.so.6.
>
> I am compiling my program on an (older) system with 8.2.4 installed and I need have my program running on a production system running 8.3.5 or higher. This seems to work fine, but for other reasons I wanted to upgrade my "compile system" with 8.3.5 and this started to give me the error mentioned above.
>
> An ldd on the program gives:
>
> libecpg.so.6 => /usr/local/Packages/pgsql-8.3.5/lib/libecpg.so.6 (0xb7ed8000)
> libpq.so.5 => /usr/local/Packages/pgsql-8.3.5/lib/libpq.so.5 (0xb7ebc000)
>
> which looks to be ok. (The 8.2.4 compiled program was using libecpg.so.5.)
>
> It seems to me that somehow the prepare statement (first line above) is compiled into a ECPGprepare() call with 5 parameters, but using a library function with only 3 parameters, even though it points to the libecpg.so.6, which includes code having the 5 parameter ECPGprepare() function.
>
> All PostgreSQL systems are natively installed from source on the various systems, i.e. compiled individually on each system. All my systems are running Linux, but with different versions of Linux.
>
> I have also tried the very newest version 8.4rc1, but with same result, the error above.
>
> Please help,
>
> Leif
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

---

Microsoft brings you a new way to search the web. Try Bing™ now

leif@crysberg.dk wrote:
>    I have a problem when upgrading from 8.2.4 to 8.3/8.4 using ecpg with a prepare statement:
> 
> EXEC SQL PREPARE execquery FROM :stmt; line = __LINE__;
> EXEC SQL AT :_thisDbConn DECLARE execcurs CURSOR FOR execquery; line = __LINE__;
> EXEC SQL AT :_thisDbConn OPEN execcurs; line = __LINE__;
> EXEC SQL ALLOCATE DESCRIPTOR execdesc; line = __LINE__;
> 
>    I get an "SQL error: invalid statement name "(null)" on line ##" (3rd line above) on the OPEN cursor statement.

You have two different connections, right?
And you PREPARE the statement on one connection and then use it on the other, right?

This used to work because prepared statements were treated as global in 8.2, while from
8.3 on a prepared statement belongs to a specific connection.

The change in the source code was made here:
http://archives.postgresql.org/pgsql-committers/2007-09/msg00408.php

This makes prepared statements thread-safe, which is more sane anyway.

If you look at the C file output by the preprocessor, you'll find
in 8.2 something like:

      { ECPGdo(__LINE__, 0, 1, _thisDbConn, "declare execcurs  cursor  for ?", 
      ECPGt_char_variable,(ECPGprepared_statement("execquery")),(long)1,(long)1,(1)*sizeof(char), 
      ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);

and in 8.4 something like:

      { ECPGdo(__LINE__, 0, 1, _thisDbConn, 0, ECPGst_normal, "declare execcurs cursor for $1", 
      ECPGt_char_variable,(ECPGprepared_statement(_thisDbConn, "execquery",
__LINE__)),(long)1,(long)1,(1)*sizeof(char),
 
      ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);

So you see, the ECPGprepared_statement function used to treate a prepared statement
as something global rather than belonging to a certain connection.


The solution is to fix your program so that it uses a prepared statement
only on the connection where you prepared it.

Yours,
Laurenz Albe