* Tom Lane:
> Florian Weimer <fw@deneb.enyo.de> writes:
>> By the way, the binary encoding would be pretty useful for BYTEA
>> columns and parameters, but it's a pretty hefty burden for almost
>> anything else. Wouldn't it make sense to add a format flag which
>> basically says "binary if it's BYTEA, otherwise text"?
>
> What is "easy" is very much in the eye of the beholder --- I would think
> for instance that a lot of people would consider integer columns to be
> easy enough to deal with in binary format. ntohl() isn't much of a
> burden.
The documentation is silent on alignment, so I would have thought that
a memcpy() is needed, too.
> As far as output goes, I seem to recall some discussion awhile back of a
> format value that would mean "send <some list of types> in binary" where
> the specific list could be set by the client. This would seem to me to
> be a lot more useful and less klugy than hard-wiring bytea as a special
> case.
Yes, but it would be more difficult to implement, wouldn't it? (Of
course, it's better to implement the full-blown version from the
beginning if it is implemented ever.)
> On the input side it's much more questionable since (as you noted)
> clients don't always have a solid grasp on which parameters are
> which types.
The input side is actually *much* *more* problematic because right
now, I've got this string, and I pass it to PostgreSQL, and depending
on the query, I've got to BYTEA-encode it or not. There is no way to
figure out if this is necessary for a particular parameter. If I
specify a BYTEA type for all string columns, I break type enference
(there's no conversion or cast for BYTEA to INTEGER, for instance).
As a result, if you use BYTEA columns from one of the scripting
languages, you end up with manually specificing BYTEA types. I hate
that, and people forget it and complain when things break.
In contrast, for the output side, I can look at the column type and
decode the value if it's BYTEA. It's just an efficiency issue. The
API itself isn't problematic.
