Re: COPY IN/BOTH vs. extended query mode

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.

In response to

Browse pgsql-hackers by date

  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