Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 7B713634756
	for <pgsql-interfaces-postgresql.org@mail.postgresql.org>;
	Sun,  7 Jun 2009 08:00:45 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024) with ESMTP id 02931-08
	for <pgsql-interfaces-postgresql.org@mail.postgresql.org>;
	Sun,  7 Jun 2009 08:00:44 -0300 (ADT)
Received: from mx1.hub.org (unknown [200.46.208.106])
	by mail.postgresql.org (Postfix) with ESMTP id 0D572632397
	for <pgsql-interfaces@postgresql.org>;
	Sun,  7 Jun 2009 07:22:43 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167])
	by mx1.hub.org (Postfix) with ESMTP id 452C71259CE5
	for <pgsql-interfaces@postgresql.org>;
	Sun,  7 Jun 2009 07:22:42 -0300 (ADT)
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de)
	by mail.enyo.de with esmtp id 1MDFWK-0006i4-O8;
	Sun, 07 Jun 2009 12:22:32 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.69)
	(envelope-from <fw@deneb.enyo.de>)
	id 1MDFWK-000280-Aq; Sun, 07 Jun 2009 12:22:32 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Type OIDs
References: <877hztupfn.fsf@mid.deneb.enyo.de>
	<10172.1244057188@sss.pgh.pa.us> <87r5xxwt3s.fsf@mid.deneb.enyo.de>
	<9704.1244301302@sss.pgh.pa.us>
Date: Sun, 07 Jun 2009 12:22:32 +0200
In-Reply-To: <9704.1244301302@sss.pgh.pa.us> (Tom Lane's message of "Sat, 06
	Jun 2009 11:15:02 -0400")
Message-ID: <87iqj81gyf.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.1 tagged_above=0 required=5 tests=RDNS_NONE=0.1
X-Spam-Level: 
X-Archive-Number: 200906/6
X-Sequence-Number: 6874

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