From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY IN/BOTH vs. extended query mode |
Date: | 2017-02-19 17:37:08 |
Message-ID: | CADkLM=doeiWQX4AGtDNG4PsWfSXz3ai7kY=PZm3sUhsUeev9Bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 19, 2017 at 9:04 AM, Robert Haas <robertmhaas(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim Gündüz | 2017-02-19 18:09:08 | Re: drop support for Python 2.3 |
Previous Message | Fabien COELHO | 2017-02-19 17:34:25 | Re: [pgsql-www] Small issue in online devel documentation build |