| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Karol Trzcionka <karlikt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: RETURNING syntax for COPY |
| Date: | 2013-05-08 17:16:14 |
| Message-ID: | 2143.1368033374@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 08.05.2013 19:44, Tom Lane wrote:
>> 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
That would require the backend to buffer the entire query response,
which isn't a great idea. I would expect that such an operation would
need to interleave CopyData to the backend with DataRow responses. Such
a thing could possibly be built on COPY_BOTH mode, but it would be a lot
of work (at both ends) for extremely debatable value.
The general idea of COPY is to load data as fast as possible, so weighing
it down with processing options seems like a pretty dubious idea even if
the implementation were easy.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2013-05-08 17:24:33 | Re: improving PL/Python builds on OS X |
| Previous Message | Heikki Linnakangas | 2013-05-08 16:58:34 | Re: RETURNING syntax for COPY |