pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedFrom: Florian Weimer <fw@deneb.enyo.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Type OIDs
Date: Sun, 07 Jun 2009 12:22:32 +0200
Message-ID: <87iqj81gyf.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <9704.1244301302@sss.pgh.pa.us>
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>
* 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.
view thread (6+ messages)
Message-ID: <87iqj81gyf.fsf@mid.deneb.enyo.de>
Permalink: ../87iqj81gyf.fsf@mid.deneb.enyo.de/
Also on: postgresql.org/message-id/87iqj81gyf.fsf@mid.deneb.enyo.de
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: fw@deneb.enyo.de, tgl@sss.pgh.pa.us
Subject: Re: Type OIDs
In-Reply-To: <87iqj81gyf.fsf@mid.deneb.enyo.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox