<p dir="ltr"><p dir="ltr">On 1 Oct. 2016 05:20, "Tom Lane" <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > Corey Huinker <<a
href="mailto:corey.huinker@gmail.com">corey.huinker@gmail.com</a>>writes:<br /> > > Attached is a _very_ rough
patchimplementing a proof-of-concept function<br /> > > copy_srf();<br /> > > ...<br /> > > As for
thatfuture direction, we could either have:<br /> > > - a robust function named something like copy_srf(), with
parametersfor<br /> > > all of the relevant options found in the COPY command<br /> > > - a function that
acceptsan options string and parse that<br /> > > - we could alter the grammar to make COPY RETURNING col1, col3,
col5FROM<br /> > > 'filename' a legit CTE.<br /> ><br /> > I think the last of those suggestions has come
upbefore. It has the<br /> > large advantage that you don't have to remember a different syntax for<br /> >
copy-as-a-function. Once you had the framework for that, other<br /> > rows-returning utility commands such as
EXPLAINmight plug in as well,<br /> > whenever somebody got enough of an itch for it.<br /><p dir="ltr">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
FETCHin non queries.<p dir="ltr">> regards, tom lane<br /> ><br /> ><br /> > --<br
/>> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> > To make changes to your
subscription:<br/> > <a
href="http://www.postgresql.org/mailpref/pgsql-hackers">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/>
