Re: Type OIDs

* 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.