Skip site navigation (1) Skip section navigation (2)

Recasting types

From: Graham Wilson <grahamwilsonca(at)yahoo(dot)ca>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Recasting types
Date: 2003-01-09 10:50:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
I have brought this up on the list before so feel free
to tell me to shut up and stop whining.  I am actually
generally quite happy with postgres but I have a few
comments on how to improve libpq...

My concern is with the lack of explicit type casting
functions in libpq.  I understand the reasoning for
passing data around in ASCII and recognize that byte
ordering and sizing is problematic when moving binary
data between machines of different types. 
Nevertheless, I feel the lack for sound type casting
of returned ASCII data returned from postgresql is a
serious shortcoming of libpq.

As we all know, for non-binary types, the returned
pointer from PQexec points to ASCII data that is
retireved as a character pointer with PQgetvalue. 
However, from a user's perspective, if the data is an
integer, then there must be some way to cast it as
such!  I don't care that the backend keeps this data
as ASCII, that is semantic.  As it stands, PQgetvalue
returns a character ointer that the programmer must
somehow cast with little knowledge of the type.  At
present, all that can be determined is the internal
oid returned by PQftype.  From this oid, one can then
do a lookup on a template database to get a character
representation of the type (i.e. "int2" or "int4"). 
Comparing this type with a list of known types then
allows one to cast the data appropriately, but it is a
large amount of unneccessary work for the application
programmer (IMHO).  Effectively, what I am asking for
is a set of abstracted tools that can parse every
postgres datatype into a suitable c type with an open
definition that is known to libpq-fe.h.

With regard to binary data, I would like to see a set
of transparent tools that can perform raw conversion
of the returned data stream. Again, why should an
application programmer have to concern himself/herself
with converting the binary stream simply because the
server has different endiness conventions than his
local machine?  This is not as difficult as one might
think... Endiness and most other binary conversions
can easily be checked during the compiling of a local
libpq and simply passing a 'known' long long integer
in the PGConn structure would provide enough
information to figure out how to mangle the binary

Please reply to the list.


Post your free ad now!


pgsql-interfaces by date

Next:From: Gerhard HintermayerDate: 2003-01-09 11:06:33
Subject: Re: still memory leaks with libpgtcl
Previous:From: Key88 SFDate: 2003-01-09 06:29:02
Subject: Re: libpqxx Large Objects

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group