Re: [HACKERS] COPY IN/BOTH vs. extended query mode

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] COPY IN/BOTH vs. extended query mode
Дата
Msg-id CA+TgmoaF6TU1CDw--keMEbG-oEpnR93nX8RoqytTWagACpFe=Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] COPY IN/BOTH vs. extended query mode  (Corey Huinker <corey.huinker@gmail.com>)
Ответы Re: [HACKERS] COPY IN/BOTH vs. extended query mode  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-hackers
On Thu, Feb 16, 2017 at 1:58 PM, Corey Huinker <corey.huinker@gmail.com> wrote:
> Forgive my ignorance, but is this issue related to the Catch-22 I had with
> "COPY as a set returning function", wherein a function that invokes
> BeginCopyFrom() basically starts a result set, but then ends it to do the
> BeginCopyFrom() having NULL (meaning STDIN) as the file, so that when the
> results from the copy come back the 'T' record that was going to preface the
> 'D' records emitted by the function is now gone?

I can't quite understand what you've written here.  I would think that
"COPY TO STDOUT", not "COPY FROM", would begin a result set.

If you were trying to write a SQL-callable function that would return
a result set by emitting protocol messages directly, I imagine that
will cause all kinds of problems, because you won't be able to keep
the result set the function produces by emitting protocol messages
cleanly separated from whatever the backend code that's calling that
function does to return whatever it views as the result of the
function call.

If you tried to write an SQL-callable function that internally started
and ended a copy from the client, then I think you would run into this
problem, and probably some others.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Gather Merge
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Parallel bitmap heap scan