Re: libpq support for arrays and composites

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq support for arrays and composites
Date: 2008-06-09 10:02:05
Message-ID: 484CFF9D.4050506@esilo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>That makes it quite useless for my intended purpose.

I found no more use cases for text results after libpqtypes started to
take shape, eventhough libpqtypes supports all data types in text &
binary excluding arrays and composites. Because of this, adding a text
parser for arrays and composites felt like a lot of work for a little
gain. libpqtypes is really designed to be a binary interface. The text
support offered allows existing applications to use the new interface
with results generated by PQexec(), meaning you can use PQgetf w/o
having to change code to use PQputf().

If you take another glance at libpqtypes, you may see that result format
decisions are pretty well abstracted and there really is no need for
text results anymore (okay, I'll catagorize that as an opinion).

> I also am not particularly enamoured of the libpqtypes way of doing
> things, which feels rather foreign to me.

Not sure we can fix this issue. We made every attempt to keep things
familiar ... printf/scanf style. It's a new approach for libpq but an
old one for C hacks.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message H.Harada 2008-06-09 12:32:58 proposal: add window function to 8.4
Previous Message Heikki Linnakangas 2008-06-09 07:52:46 Re: Automating our version-stamping a bit better