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 по дате отправления: