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=fmBVojy0uqD40_H5ozsO5s=gqavc57L=f5XK7DZGuuJw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] COPY as a set returning function  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers

Here is a 4: Refactoring BeginCopyFrom so as instead of a Relation are
used a TupleDesc, a default expression list, and a relation name. You
could as well make NextCopyFrom() smarter so as it does nothing if no
expression contexts are given by the caller, which is the case of your
function here. To be honest, I find a bit weird to use
NextCopyFromRawFields when there is already a bunch of sanity checks
happening in NextCopyFrom(), where you surely want to have them
checked even for your function.

Looking at the last patch proposed, I find the current patch proposed
as immature, as rsTupDesc basically overlaps with the relation a
caller can define in BeginCopyFrom(), so marking this patch as
"returned with feedback".
--
Michael

I like that suggestion and will move forward on it. I wasn't sure there would be support for such a refactoring.

As for the copy from stdin case, Andrew Gierth laid out why that's nearly impossible to unwind in the network protocol (the act of starting the copy causes the query result to end before any rows were returned), and that might make STDIN input a dead issue.

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Speedup twophase transactions