Re: [PATCHES] libpq type system 0.9a

>>There are many cases that are fairly hard to get a perfect mapping. If
>>you use PGtime, for instance, there are no C operators for it
>
>

Yeah, our patch is designed to allow one to interface with libpq using C data
types, rather than strings (most common) or for the brave external binary format.

>>If you try to use the C time type instead, you will
>>have many more operators available, but will lose precision.
That is why we didn't use something like struct tm. Instead, we have PGtime,
PGdate and PGtimestamp. PGtimestamp has a PGtime and PGdate in it. See
libpq-fe.h inside our patch.

/* Below is a PGtime. */
typedef struct
{
/* The number of hours past midnight, in the range 0 to 23. */
int hour;

/* The number of minutes after the hour, in the range 0 to 59. */
int min;

/* The number of seconds after the minute, in the range 0 to 59. */
int sec;

/* The number of microseconds after the second, in the
* range of 0 to 999999.
*/
int usec;

/*
* When non-zero, this is a TIME WITH TIME ZONE. Otherwise,
* it is a TIME WITHOUT TIME ZONE.
*/
int withtz;

/* A value of 1 indicates daylight savings time. A value of 0 indicates
* standard time. A value of -1 means unknown or could not determine.
*/
int isdst;

/* Seconds east of UTC. This value is not always available. It is
* set to 0 if it cannot be determined.
*/
int gmtoff;

/* Timezone abbreviation: such as EST, GMT, PDT, etc. This value is
* not always available. It is set to an empty string if it cannot be
* determined. It can also be in ISO 8601 GMT+/-hhmmss format.
*/
char tzname[16];
} PGtime;

Our patch was not designed to operate on these data types, although it could
with a little work. It sounds like people would like this functionality, some
referring to ecpg.

Numeric is a the odd ball in our patch. We saw no benefit to supplying a struct
for it so we always expose numerics as strings (put or get). Internally, we
convert the string to binary format for puts. On binary gets, we convert the
external format to a numeric string. We left it to the libpq user to strtod or
use a Big Number library.

>>And I think NULL is still particularly tricky
PQgetisnull is used by our code. It doesn't error out, but after zeroing the
provided user memory, it just returns. The libpq user should check isnull where
they care about it.

Almost all of the types that required a PGstruct, are very solid mappings. For
instance, geo types are straight forward, not much to a PGpoint. Geo type
structs were kept very close to the backend.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/