BUG #6309: ECPG pre-processor issue - Mailing list pgsql-bugs

From Andrew Milne
Subject BUG #6309: ECPG pre-processor issue
Date
Msg-id 201111251251.pAPCppNC077000@wwwmaster.postgresql.org
Whole thread Raw
Responses Re: BUG #6309: ECPG pre-processor issue
List pgsql-bugs
The following bug has been logged online:

Bug reference:      6309
Logged by:          Andrew Milne
Email address:      Andrew.Milne@iongeo.com
PostgreSQL version: 8.4.9
Operating system:   Red Hat Enterprise Linux Workstation release 6.1
(Santiago)
Description:        ECPG pre-processor issue
Details:

NOTE: While I've not tested on 9.1 I can see the same code exists in that
release and as such the error will most likely still occur.  Unfortunately I
can't upgrade from 8.4.9 due to project wide considerations.

The ECPG pre-processor seems to be incorrectly reporting an error when
parsing "EXEC SQL AT :cnx DEALLOCATE..." style commands.

For example:

===============================================
EXEC SQL AT :cnx DEALLOCATE thestatementname;
===============================================

results in the pre-processor outputting an error:

===============================================
src.pcpp:1000: ERROR: AT option not allowed in DEALLOCATE statement
===============================================

However if you examine the generated src.cpp file it appears to have
correctly generated code that uses the connection:

===============================================
{ ECPGdeallocate(__LINE__, 0, cnx, "thestatementname");
===============================================

And examining the source code for ECPGdeallocate it correctly handles the
supplied connection.

Examining the pre-processor (preproc.y) seems to show this error has no
impact on the actual processing of the file and is probably just a holdover
from earlier versions of ECPG.

The project I'm working on has multiple ECPG connections open and we need to
be able to prepare and deallocate to the correct connection.  Our intention
is to simply ignore the preprocessor error at this time but it would be good
to:

1. Get some confirmation that this is safe to do
2. If someone with a decent knowledge of postgress could actually look into
fixing the issue it would be appreciated (my understanding is limited and I
wouldn't be confident putting forward a patch myself).

Thanks

A Milne

pgsql-bugs by date:

Previous
From: "Thomas Goerner"
Date:
Subject: BUG #6308: Problem w. encoding in client
Next
From: "Sidar Lopez"
Date:
Subject: BUG #6310: Startup Script