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 <kleptog@svana.org> 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
