| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de> |
| Cc: | pgsql-interfaces(at)postgresql(dot)org |
| Subject: | Re: Type OIDs |
| Date: | 2009-06-06 15:15:02 |
| Message-ID: | 9704.1244301302@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
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.
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. 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Weimer | 2009-06-07 10:22:32 | Re: Type OIDs |
| Previous Message | Florian Weimer | 2009-06-06 10:32:07 | Re: Type OIDs |