Re: 7.4 COPY BINARY Format Change
| От | Tom Lane |
|---|---|
| Тема | Re: 7.4 COPY BINARY Format Change |
| Дата | |
| Msg-id | 7926.1060018700@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: 7.4 COPY BINARY Format Change (Lee Kindness <lkindness@csl.co.uk>) |
| Список | pgsql-hackers |
Lee Kindness <lkindness@csl.co.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
В списке pgsql-hackers по дате отправления: