From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Karol Trzcionka <karlikt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RETURNING syntax for COPY |
Date: | 2013-05-08 16:58:34 |
Message-ID: | 518A843A.3020408@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08.05.2013 19:44, Tom Lane wrote:
> Karol Trzcionka<karlikt(at)gmail(dot)com> writes:
>> as a continuation of my proposal expanding RETURNING syntax by
>> AFTER/BEFORE, there can be enough time to implement RETURNING for COPY.
>
> No there isn't; what you suggest would require FE/BE protocol
> extensions, making it several orders of magnitude more work than the
> other thing.
I'd imagine that the flow would go something like this:
BE FE
CopyInResponse
CopyData
CopyData
...
CopyDone
RowDescription
DataRow
DataRow
CommandComplete
A well-written client should be able to handle that. But if one expects
the backend to always send a CommandComplete after CopyDone, it will get
confused. Implementing that doesn't seem too difficult to me.
I agree that this is much more work than the UPDATE RETURNING
BEFORE/AFTER, though. Not sure if that's a good or a bad thing.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-05-08 17:16:14 | Re: RETURNING syntax for COPY |
Previous Message | Tom Lane | 2013-05-08 16:44:59 | Re: RETURNING syntax for COPY |