Re: [HACKERS] COPY as a set returning function

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: [HACKERS] COPY as a set returning function
Дата
Msg-id CADkLM=fmBVojy0uqD40_H5ozsO5s=gqavc57L=f5XK7DZGuuJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] COPY as a set returning function  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers

Here is a 4: Refactoring BeginCopyFrom so as instead of a Relation are
used a TupleDesc, a default expression list, and a relation name. You
could as well make NextCopyFrom() smarter so as it does nothing if no
expression contexts are given by the caller, which is the case of your
function here. To be honest, I find a bit weird to use
NextCopyFromRawFields when there is already a bunch of sanity checks
happening in NextCopyFrom(), where you surely want to have them
checked even for your function.

Looking at the last patch proposed, I find the current patch proposed
as immature, as rsTupDesc basically overlaps with the relation a
caller can define in BeginCopyFrom(), so marking this patch as
"returned with feedback".
--
Michael

I like that suggestion and will move forward on it. I wasn't sure there would be support for such a refactoring.

As for the copy from stdin case, Andrew Gierth laid out why that's nearly impossible to unwind in the network protocol (the act of starting the copy causes the query result to end before any rows were returned), and that might make STDIN input a dead issue.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Speedup twophase transactions