Re: [HACKERS] COPY IN/BOTH vs. extended query mode - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: [HACKERS] COPY IN/BOTH vs. extended query mode
Date
Msg-id CADkLM=doeiWQX4AGtDNG4PsWfSXz3ai7kY=PZm3sUhsUeev9Bg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] COPY IN/BOTH vs. extended query mode  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, Feb 19, 2017 at 9:04 AM, Robert Haas <robertmhaas@gmail.com> 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 submitted that allowed someone to do this

insert into some_table(id, total_sum) select id, sum(a_numeric_metric) from copy_srf('/a/file/name') group by 1
or
insert into some_table(id, total_sum) select id, sum(a_numeric_metric) from copy_srf('/a/program/name arg1 arg2',true) group by 1

and those worked just fine, however, attempts to use the STDIN

insert into some_table(id, total_sum) select id, sum(a_numeric_metric) from copy_srf(null) group by 1

failed, because as it was explained to me, the order of such events would be:

1. start query
2. send result set format to client
3. start copy which implies that query result set is done
4. finish copy
5. emit query results to client, but the defining result format is gone, thus error.

I'm just putting this here for future reference in case there is a protocol change in the works.

 

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [pgsql-www] [HACKERS] Small issue in online devel documentationbuild
Next
From: Devrim Gündüz
Date:
Subject: Re: [HACKERS] drop support for Python 2.3