From: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Type OIDs |
Date: | 2009-06-07 10:22:32 |
Message-ID: | 87iqj81gyf.fsf@mid.deneb.enyo.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
* Tom Lane:
> Florian Weimer <fw(at)deneb(dot)enyo(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ralf Hasemann | 2009-07-23 19:47:06 | Linker Confusion..... |
Previous Message | Tom Lane | 2009-06-06 15:15:02 | Re: Type OIDs |