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

From Corey Huinker
Subject Re: [HACKERS] COPY as a set returning function
Date
Msg-id CADkLM=eOv4LGOFUO=ir_nZvhGjPoTwndiiM9UZc2DH_Pb6Ldcg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] COPY as a set returning function  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] COPY as a set returning function  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Fri, Jan 27, 2017 at 9:42 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 1/25/17 8:51 PM, Corey Huinker wrote:
> # select * from copy_srf('echo "x\ty"',true) as t(x text, y text);

I find these parameters weird.  Just looking at this, one has no idea
what the "true" means.  Why not have a "filename" and a "program"
parameter and make them mutually exclusive?

It was done that way to match the parameters of BeginCopyFrom() and it could easily be changed.

I suppose I could have written it as:
select * from copy_srf(filename => 'echo "x\ty"', is_program => true) as t(x text, y text);

But this goes to the core of this patch/poc: I don't know where we want to take it next.

Options at this point are:
1. Continue with a SRF, in which case discussions about parameters are completely valid.
2. Add a RETURNING clause to COPY. This would dispense with the parameters problem, but potentially create others.
3. Add the TupDesc parameter to BeginCopyFrom, make sure all data structures are visible to an extension, and call it a day. If someone wants to write an extension that makes their own copy_srf(), they can.
4. Someone else's better idea.


 

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Proposal : For Auto-Prewarm.
Next
From: Nikita Glukhov
Date:
Subject: Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops