Re: Column info without executing query

From: <Mitch(dot)Logue(at)tdameritrade(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Column info without executing query
Date: 2006-07-21 14:47:55
Message-ID: 6A6C88E023CEAE4186002016A357161D077D6E38@prdhqwsemlmb01.prod-am.ameritrade.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


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: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-owner(at)postgresql(dot)org] 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(at)postgresql(dot)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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2006-07-21 15:13:32 Impact of vacuum full...
Previous Message Volkan YAZICI 2006-07-21 14:47:32 Re: Column info without executing query