Re: COPY as a set returning function

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: COPY as a set returning function
Дата
Msg-id 30244.1475290584@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: COPY as a set returning function  (Craig Ringer <craig.ringer@2ndquadrant.com>)
Ответы Re: COPY as a set returning function  (Corey Huinker <corey.huinker@gmail.com>)
Re: COPY as a set returning function  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
Craig Ringer <craig.ringer@2ndquadrant.com> writes:
> On 1 Oct. 2016 05:20, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> I think the last of those suggestions has come up before.  It has the
>> large advantage that you don't have to remember a different syntax for
>> copy-as-a-function.

> That sounds fantastic. It'd help this copy variant retain festure parity
> with normal copy. And it'd bring us closer to being able to FETCH in non
> queries.

On second thought, though, this couldn't exactly duplicate the existing
COPY syntax, because COPY relies heavily on the rowtype of the named
target table to tell it what it's copying.  You'd need some new syntax
to provide the list of column names and types, which puts a bit of
a hole in the "syntax we already know" argument.  A SRF-returning-record
would have a leg up on that, because we do have existing syntax for
defining the concrete rowtype that any particular call returns.
        regards, tom lane



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Hash Indexes
Следующее
От: Pavel Raiskup
Дата:
Сообщение: [PATCH] parallel & isolated makefile for plpython