Re: raw output from copy
От | Craig Ringer |
---|---|
Тема | Re: raw output from copy |
Дата | |
Msg-id | CAMsr+YGc95in1Ruu0sknKCe-USfj+8Ca1byP1p-s0D=pDU59+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: raw output from copy (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: raw output from copy
|
Список | pgsql-hackers |
On 7 July 2015 at 14:32, Pavel Stehule <pavel.stehule@gmail.com> wrote: > Hi > > previous patch was broken, and buggy > > Here is new version with fixed upload and more tests I routinely see people trying to use COPY ... FORMAT binary to export a single binary field (like an image, for example) and getting confused by the header PostgreSQL adds. Or using text-format COPY and struggling with the hex escaping. It's clearly something people have trouble with. It doesn't help that while lo_import and lo_export can read paths outside the datadir (and refuse to read from within it), pg_read_binary_file is superuser only and disallows absolute paths. There's no corresponding pg_write_binary_file. So users who want to import and export a single binary field tend to try to use COPY. We have functionality for large objects that has no equivalent for 'bytea'. I don't love the use of COPY for this, but it gets us support for arbitrary clients pretty easily. Otherwise it'd be server-side only via local filesystem access, or require special psql-specific functionality like we have for lo_import etc. The main point is that this is a real world thing. People want to do it, try to do it, and have problems doing it. So it's a solution a real issue. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: