On 1 Oct. 2016 05:20, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > Corey Huinker <corey.huin...@gmail.com> writes: > > Attached is a _very_ rough patch implementing a proof-of-concept function > > copy_srf(); > > ... > > As for that future direction, we could either have: > > - a robust function named something like copy_srf(), with parameters for > > all of the relevant options found in the COPY command > > - a function that accepts an options string and parse that > > - we could alter the grammar to make COPY RETURNING col1, col3, col5 FROM > > 'filename' a legit CTE. > > 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. Once you had the framework for that, other > rows-returning utility commands such as EXPLAIN might plug in as well, > whenever somebody got enough of an itch for it.
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. > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
