> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment