Andrew Chernow <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Better support for arrays and composites is certainly something that
>> people might want, but the problem with this design is that it forces
>> them to buy into a number of other decisions that they don't necessarily
>> want.
> What decisions are we forcing upon the libpq user?
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks for
benefits that may not be meaningful for their apps.
The other forced decision is the whole PQputf/PQgetf notation, which
people may or may not find natural --- it still seems a pretty poor
choice to me for this specific problem. PQputf, in the form where
you're generating a SQL command string along with some parameters,
isn't too unreasonable, but unless you've already bought into binary
parameter handling it's not gaining all that much either. And
PQgetf is just weird. The format of a PGresult is generally well
known by the app; trying to force it into the model of string
scanning is a poor fit. For instance there's no mapping at all
for what to do with constant parts of the format string.
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
