By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,903 Members | 1,086 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,903 IT Pros & Developers. It's quick & easy.

ECPG bug or development choice

P: n/a
Hi,

I'm not sure it's a bug or it's normal, so i don't send it to pgsq-bugs.

Well, i have written pgbench in PRO*C to have a common pgbench.pgc
source for Postgres and Oracle.
However, there are some differences between the Postgres Pro*c and
Oracle Pro*c.

So, i use #ifdef ORACLE #else #endif preprocessing instructions to
differentiate PG from Oracle Pro*c syntaxes.

This works fine with Oracle Pro*c but EGPG tries to translate the code
into #ifdef ORACLE #endif blocks and FAILS with the message : "ERROR :
INVALID DATA TYPE ...".
That means cpp is not called by ECPG but is more or less called by PROC
ORACLE.

For example, this following code : test.pgc

#include <stdlib.h>

main()
{
printf("Before define\n");
#ifdef ORACLE
sql_context ctx;
EXEC SQL CONTEXT USE :ctx;
EXEC SQL CONNECT "scott/tiger";
#else
EXEC SQL CONNECT TO template1 as "cnx_init";
#endif
printf("After endif\n");
}

ecpg -o test.c test.pgc
returns :
test.pgc:8: INVALID DATA TYPE 'CONTEXT'

But by doing the following commands :
cpp -E -o testE.pgc test.pgc
ecpg -o test.c testE.pgc

is OK.

So, is there an other solutions to share EXEC SQL instructions between
Postgres and Oracle ?

Best regards,
Thierry.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 11 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Tue, Sep 09, 2003 at 02:48:19PM +0200, Thierry Missimilly wrote:
I'm not sure it's a bug or it's normal, so i don't send it to pgsq-bugs.
...
So, i use #ifdef ORACLE #else #endif preprocessing instructions to
differentiate PG from Oracle Pro*c syntaxes.


As a matter of fact we use EXEC SQL IFDEF, ... and do not parse any
C/CPP code. running cpp before parsing leads to undesirable side
effects.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: me****@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 11 '05 #2

P: n/a
Yes, i've discovered that and Oracle uses EXEC ORACLE ifdef ....
So, that means it is not possible to have one and only one source file for a
Proc*c program which could be run on Postgres and Oracle.

Thank for your fast answer.
Thierry

Michael Meskes wrote:
On Tue, Sep 09, 2003 at 02:48:19PM +0200, Thierry Missimilly wrote:
I'm not sure it's a bug or it's normal, so i don't send it to pgsq-bugs.
...
So, i use #ifdef ORACLE #else #endif preprocessing instructions to
differentiate PG from Oracle Pro*c syntaxes.


As a matter of fact we use EXEC SQL IFDEF, ... and do not parse any
C/CPP code. running cpp before parsing leads to undesirable side
effects.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: me****@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.