From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Andrew Chernow <ac(at)esilo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq support for arrays and composites |
Date: | 2008-06-09 07:00:15 |
Message-ID: | 5994.1212994815@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Lastly, the idea is to provide extra facilities to libpq clients
> without requiring any extra library.
Or more to the point, without requiring boatloads of new code that
only some libpq users would have any use for.
To my mind, the point of the present proposal is to provide some
client-side code that understands how to invert the data
formatting/escaping rules implemented by array_out, record_out,
and perhaps array_in/record_in. We can make that happen without
taking a quantum jump in libpq's API complexity --- and offhand
it seems that Andrew D's proposal is at about the right level of
complication. libpqtypes has its place also, but I think it's
addressing a different level of problem complexity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-06-09 07:52:46 | Re: Automating our version-stamping a bit better |
Previous Message | Tom Lane | 2008-06-09 06:30:55 | Message-ID should surely not be shown as a mailto: URL |