Re: COPY as a set returning function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COPY as a set returning function
Date
Msg-id 30244.1475290584@sss.pgh.pa.us
Whole thread Raw
In response to Re: COPY as a set returning function  (Craig Ringer <craig.ringer@2ndquadrant.com>)
Responses 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>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Hash Indexes
Next
From: Pavel Raiskup
Date:
Subject: [PATCH] parallel & isolated makefile for plpython