| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Lee Kindness <lkindness(at)csl(dot)co(dot)uk> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 7.4 COPY BINARY Format Change |
| Date: | 2003-08-04 17:38:20 |
| Message-ID: | 7926.1060018700@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Lee Kindness <lkindness(at)csl(dot)co(dot)uk> writes:
> Would I be right is guessing a binary CURSOR would return in values in
> the same format as a binary COPY, hence your expectation of more
> individual transfers/conversions? Actually with the new FE/BE protocol
> there is little call for the binary cursor now, yeah?
Binary cursors per se are obsolete --- you can get the result of any
query in binary form, if you ask politely. And you can send data in
binary form, too, using parameters. I have not gotten around to
benchmarking a prepared INSERT with binary parameters against a binary
COPY, but I expect the differential is not nearly as bad as it is for a
source-form INSERT. It could well be that binary COPY is obsolete for
the purposes you're using it for.
> so they don't stop at just giving you a blob of binary data and saying
> it has n fields - functions would be available to iterate over the
> fields and get the data out in a format which is immediately
> useful.
You can iterate over the fields of a text COPY and get the data out,
too, if you think it useful. I haven't seen a huge call for support
for that, and so I don't believe it's important for binary COPY either.
I do see a need for converting individual binary data values in the
context of query parameters and results.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2003-08-04 17:40:14 | Re: problem with RH7.3 Pg7.3.4 binaries |
| Previous Message | Larry Rosenman | 2003-08-04 17:23:14 | Re: Thread-safe configuration option appears to |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anne Dudfield | 2003-08-04 18:40:35 | Patch for select() -> poll() in libpq |
| Previous Message | Joe Conway | 2003-08-04 17:11:06 | Re: [HACKERS] statement level trigger causes pltcl, plpython |