Re: Extending copy_expert

Поиск
Список
Период
Сортировка
Искать
От
Daniele Varrazzo
Тема
Re: Extending copy_expert
Дата
Msg-id
CA+mi_8Znj1x9dvR-4rWcxm6ccA+g+Nnu0+FdEc6wF96VW34cnQ@mail.gmail.com
Ответ на
Re: Extending copy_expert (Andrea Riciputi)
Список
Дерево обсуждения
Extending copy_expert Andrea Riciputi <andrea.riciputi@gmail.com>
Re: Extending copy_expert Adrian Klaver <adrian.klaver@aklaver.com>
Re: Extending copy_expert Adrian Klaver <adrian.klaver@aklaver.com>
Re: Extending copy_expert Andrea Riciputi <andrea.riciputi@gmail.com>
Re: Extending copy_expert Adrian Klaver <adrian.klaver@aklaver.com>
Re: Extending copy_expert Christophe Pettus <xof@thebuild.com>
Re: Extending copy_expert Daniele Varrazzo <daniele.varrazzo@gmail.com>
Re: Extending copy_expert Rich Shepard <rshepard@appl-ecosys.com>
On Mon, Oct 13, 2014 at 9:49 PM, Andrea Riciputi
 wrote:
> In my opinion it’d be better to push such a feature upstream to PG, but even having it in psycopg could be a good compromise. Do you have any strong argument against such a feature in psycopg? Do you think it’d be better part of PG itself? If so, how do you think I can gain support in the pgsql-hackers ml?

Psycopg doesn't do much here: it receives buffers via PQgetCopyData
[1] and forwards them to the Python file in argument. You could easily
hack the function and replace the \n into \r\n in C, but this would
still imply a copy so I'm not sure it would be more efficient than
running copy from psql to stdout and piping the result througn sed
's/$/\r/', leaving Python entirely out of the equation.

[1] http://www.postgresql.org/docs/9.3/static/libpq-copy.html#LIBPQ-PQGETCOPYDATA

-- Daniele

В списке psycopg по дате отправления
От: Andrea Riciputi
Дата:
Сообщение: Re: Extending copy_expert
От: Adrian Klaver
Дата:
Сообщение: Re: Extending copy_expert
FAQ