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: | Raw Message | Whole Thread | 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 |