[GENERAL] Including C/C++ header files containing #defines using EXEC SQL INCLUDE

[Mitch.Logue]

Title: Including C/C++ header files containing #defines using EXEC SQL INCLUDE







Here is the problem I am trying to solve:


I have Header files (C and C++) that check to ensure you don't load them twice by doing the following:


#ifndef MY_HDR_FILE

#define MY_HDR_FILE

Blah

Blah

Blah

#endif MY_HDR_FILE


I would like to be able to include these using EXEC SQL INCLUDE inside a EXEC SQL BEGIN/END block, but as I have seen in my readings from the Postgres groups and Google searches it seems that these types of #defines are nor parsed by the Postgres pre-processor and only handled by the C/C++ Pre-Processor (but I'd also like to point out that the only references to this issue was from a post back in 1999, so since then, there could have been changes that I'm just not aware of how to use -- he says hopefully).  But, because I'm porting from Oracle, all my code does this legally in Oracle (Pro*C), I'm not saying that makes it right, but I am asking if there is a way of doing this using Postgres?

I'm building these applications using ecpg (PostgreSQL 8.1.3) 4.1.1 on a Linux system:

Linux version 2.4.21-37.0.1.ELsmp ([EMAIL PROTECTED]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)) #1 SMP Wed Jan 11 18:44:17 EST 2006

Any assistance in this would be greatly appreciated, otherwise I am going to have to re-write a great many header files, and then also modify the source code that calls it so it only calls the C/C++ header portion because I can't keep each separate program from re-loading the header files without the #define's.

Thank you in advance

Re: [GENERAL] Column info without executing query

[Mitch.Logue]

My question is a bit off the path that you're taking with this issues, but I'd 
like to add a twist to the discussion -- to meet my needs of course :)

Is it possible to simply retrieve Column Type (Numeric, Varchar, Int,...) data 
for a given table using ecpg?

The reason I ask is that when I write in C/C++ and do a memset to NULL ('\0') 
on a struct to use as an Input for a table, if I do not receive a value for a 
Numeric data type from the calling program, I get this error:

ERROR: -400 'invalid input syntax for type numeric: ""'

I'm guessing this error is associated with the fact that the Struct Member is 
NULL, and it doesn't like that.

So, I get around the "problem" all right, but I'd prefer to not have to hard 
code this "fix" in my code for each Numeric field.  I'd prefer grabbing the 
"Format" of the table and then only calling this "fix" function when the column 
I'm inserting into is of type Numeric.

But, I don't want to have any associated Query or Select that was executed 
first, as this Thread seems to be mostly dealing with.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martijn van 
Oosterhout
Sent: Friday, July 21, 2006 9:25 AM
To: Volkan YAZICI
Cc: Jacob Coby; Dan Strömberg; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Column info without executing query

On Fri, Jul 21, 2006 at 05:07:08PM +0300, Volkan YAZICI wrote:
> AFAICS, that's not possible with current parsing capabilities. See 
> related lines in
> 
> fe-protocol3.c:pqParseInput3()
> 102 /*
> 103  * Can't process if message body isn't all here yet.
> 104  */
> 
> But, IMNSHO, we can modify parsing functionality to process message 
> parts step by step. For instance, in the current behaviour when we 
> receive a T, D, D, ... message, libpq won't attempt to process data 
> until it receives whole data chunk. But with some modification on the 
> parser side, we can make it process data in such a way:

Actually, you're wrong. It processes the T as it comes in, and then each D as 
it comes in. "message body" in this case refers to a single 'T' or 'D' record, 
not the entire query result.

> But in this case, some advanced function routines must be written to 
> access conn->result in a hardcoded way under strict control. Because,
> PQgetReesult() won't work properly till it receives whole result set.

Did you see my comment about get partial result sets from libpq. for 
asyncronous queries you can run PQftype as soon as you've received and parsed 
the T record, you don't actually have to have received any data yet... See 
pqPrepareAsyncResult().

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org