Bug #904: Deallocating of prepared statement in ECPG at COMMIT

From: pgsql-bugs(at)postgresql(dot)org
To: pgsql-bugs(at)postgresql(dot)org
Subject: Bug #904: Deallocating of prepared statement in ECPG at COMMIT
Date: 2003-02-27 11:35:19
Message-ID: 20030227113519.37C69474E4F@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers pgsql-interfaces

Jiri Langr (jiri(dot)langr(at)konero(dot)cz) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
Deallocating of prepared statement in ECPG at COMMIT

Long Description
When I prepare a statement in ECPG it lives only to first explicit transaction block. At the COMMIT it seems to be deallocated.

It is not good behavior because the main advantage of prepared statements is once prepare and many times execute!

Sample Code
ESQL/C code
********************************************
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define DBNAME "langr"

/* Testing of any SQL error, printing error message and exit */
void test(int l_exit) {
if(sqlca.sqlcode < 0) {
printf("Error: %s\n", sqlca.sqlerrm.sqlerrmc);
if(l_exit) {
EXEC SQL DISCONNECT;
exit(-1);
}
}
}

/* Demonstration of error concerning the DEALLOCATEing of PREPARED statement
at the COMMIT in PostgreSQL ESQL/C */
int main() {

EXEC SQL BEGIN DECLARE SECTION;
char dbname[64] = DBNAME;
char sql_string[1000];
int l_id;
char l_name[10 + 1];
EXEC SQL END DECLARE SECTION;

ECPGdebug(1, stderr);

/* Creating DB and connecting to them */
/* strcpy(dbname, DBNAME); */
EXEC SQL CONNECT TO :dbname;
test(1);
EXEC SQL SET AUTOCOMMIT TO ON;
test(1);

/* Creating table */
EXEC SQL DROP TABLE test;
test(0); /* no exiting because it has not to exist yet */
EXEC SQL CREATE TABLE test (
id INTEGER NOT NULL,
name CHAR(10)
);
test(1);

/* Preparing INSERT statement */
strcpy(sql_string, "INSERT INTO test VALUES(?, ?)");
EXEC SQL PREPARE prep_ins FROM :sql_string;
test(1);

/* Inserting several rows in one transaction */
EXEC SQL BEGIN;
test(1);
for(l_id = 0; l_id < 3; l_id++) {
switch(l_id) {
case 0: strcpy(l_name, "First"); break;
case 1: strcpy(l_name, "Second"); break;
case 2: strcpy(l_name, "Third"); break;
}
EXEC SQL EXECUTE prep_ins USING :l_id, :l_name;
test(1);
}
EXEC SQL COMMIT;
test(1);

/* It did work well, but the statement was DEALLOCATED automatically - WHY?? */

/* Inserting next line in separate transaction */
l_id = 3;
strcpy(l_name, "Fourth");
EXEC SQL BEGIN;
test(1);
EXEC SQL EXECUTE prep_ins USING :l_id, :l_name;
test(0); /* no exiting becase it doesn't work!! the statement doesn't exist */
EXEC SQL COMMIT;
test(1);

EXEC SQL BEGIN;
test(1);
EXEC SQL DECLARE cur_test CURSOR FOR SELECT * FROM test;
test(1);
EXEC SQL OPEN cur_test;
test(1);
while(1) {
EXEC SQL FETCH cur_test INTO :l_id, :l_name;
test(1);
if(sqlca.sqlcode == ECPG_NOT_FOUND) break;
printf("%d: %s\n", l_id, l_name);
}
EXEC SQL CLOSE cur_test;
test(1);
EXEC SQL COMMIT;
test(1);

EXEC SQL FREE prep_ins;
test(0); /* no exiting becase it doesn't work!! the statement doesn't exist */
EXEC SQL DROP TABLE test;
test(1);
EXEC SQL DISCONNECT;
test(1);
return(0);
}

SQL code doing the same funcionality and work well!!
*****************************************************

/* Demonstration of the same functionality in SQL, where it DOES work well */

/* Creating table */
CREATE TABLE test (
id INTEGER NOT NULL,
name CHAR(10)
);

/* Preparing INSERT statement */
PREPARE prep_ins(INTEGER, CHAR) AS INSERT INTO TEST VALUES($1, $2);

/* Inserting several rows in one transaction */
BEGIN;
EXECUTE prep_ins (0, 'First');
EXECUTE prep_ins (1, 'Second');
EXECUTE prep_ins (2, 'Third');
COMMIT;

/* In SQL in the difference of ESQL/C the DEALLOCATION was not don, it is well *
/
/* Inserting next line in separate transaction */
BEGIN;
EXECUTE prep_ins (3, 'Fourth');
COMMIT;

/* Reading data from the table */
SELECT * FROM test;

/* Deallocating of the statement */
DEALLOCATE prep_ins;
DROP TABLE test;

No file was uploaded with this report

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hubert depesz Lubaczewski 2003-02-27 15:47:09 Re: psql -F problems
Previous Message Tom Lane 2003-02-26 21:40:26 Re: client conx problems, 7.3.2

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Haller 2003-02-27 12:33:11 Re: Can pessimistic locking be emulated?
Previous Message Lee Kindness 2003-02-27 09:08:19 Re: ecpg in REL7_3_2

Browse pgsql-interfaces by date

  From Date Subject
Next Message Michael Meskes 2003-02-27 13:50:45 Re: ECPG: EXEC SQL execute sometimes not returning?
Previous Message Aidamir Lovpache 2003-02-27 10:13:37 Re: ECPG: EXEC SQL execute sometimes not returning?