Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Sun, Feb 19, 2017 at 9:04 AM, Robert Haas wrote: If you tried to write an SQL-callable function that internally started > and ended a copy from the client, then I think you would run into this > problem, and probably some others. > > That's it. I had a PoC patch

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Thu, Feb 16, 2017 at 1:58 PM, Corey Huinker wrote: > Forgive my ignorance, but is this issue related to the Catch-22 I had with > "COPY as a set returning function", wherein a function that invokes > BeginCopyFrom() basically starts a result set, but then ends it to do

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Mon, Feb 13, 2017 at 4:29 PM, Craig Ringer wrote: > > > On 14 Feb. 2017 06:15, "Robert Haas" wrote: > > On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas > wrote: > > According to the documentation for COPY IN mode, "If

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On 14 Feb. 2017 06:15, "Robert Haas" wrote: On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas wrote: > According to the documentation for COPY IN mode, "If the COPY command > was issued via an extended-query message, the backend will now discard >

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas wrote: > According to the documentation for COPY IN mode, "If the COPY command > was issued via an extended-query message, the backend will now discard > frontend messages until a Sync message is received, then it will issue >

[HACKERS] COPY IN/BOTH vs. extended query mode

According to the documentation for COPY IN mode, "If the COPY command was issued via an extended-query message, the backend will now discard frontend messages until a Sync message is received, then it will issue ReadyForQuery and return to normal processing." I added a similar note to the