On Wed, May 05/08/13, 2013 at 03:38:10PM -0400, Andrew Dunstan wrote:
>
> On 05/08/2013 03:23 PM, Jim Nasby wrote:
> >>WITH new_data AS (
> >>COPY FROM ...
> >>RETURNING id, field_to_check
> >>)
> >
>
> Why is this better than this, which you can do today?
>
>WITH new_data AS (
>
On 05/08/2013 03:23 PM, Jim Nasby wrote:
WITH new_data AS (
COPY FROM ...
RETURNING id, field_to_check
)
Why is this better than this, which you can do today?
WITH new_data AS (
INSERT into ... FROM foreign_table_with_file_fdw RETURNING ...
)
The whole reason I aband
On 5/8/13 12:33 PM, Dimitri Fontaine wrote:
Karol Trzcionka writes:
as a continuation of my proposal expanding RETURNING syntax by
What about implementing support for OLD/NEW in per-statement triggers? I
guess you would expose the data via a SRF.
Per statement NEW/OLD is an interesting case
On 5/8/13 12:54 PM, Jonathan S. Katz wrote:
On May 8, 2013, at 1:16 PM, Tom Lane wrote:
Heikki Linnakangas 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 thi
* Ryan Kelly (rpkell...@gmail.com) wrote:
> COPY ... RETURNING would certainly be useful to apply additional
> transformations to the data before finally sending it to its ultimate
> destination.
If we really think that COPY ... RETURNING is only going to be used in a
CTE or similar, then we could
On Wed, May 05/08/13, 2013 at 10:55:40AM -0700, David Fetter wrote:
> On Wed, May 08, 2013 at 01:16:14PM -0400, Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > On 08.05.2013 19:44, Tom Lane wrote:
> > >> No there isn't; what you suggest would require FE/BE protocol
> > >> extensions, making i
On Wed, May 08, 2013 at 01:16:14PM -0400, Tom Lane wrote:
> Heikki Linnakangas 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
On May 8, 2013, at 1:16 PM, Tom Lane wrote:
> Heikki Linnakangas 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 f
On 05/08/2013 01:16 PM, Tom Lane wrote:
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_BOT
Karol Trzcionka writes:
> as a continuation of my proposal expanding RETURNING syntax by
What about implementing support for OLD/NEW in per-statement triggers? I
guess you would expose the data via a SRF.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation e
Heikki Linnakangas 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:
> BEFE
> CopyI
On 08.05.2013 19:44, Tom Lane wrote:
Karol Trzcionka 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 order
Karol Trzcionka 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
oth
Hello
why? What is motivation? What is use case?
Regards
Pavel
2013/5/8 Karol Trzcionka
> Hello,
> as a continuation of my proposal expanding RETURNING syntax by
> AFTER/BEFORE, there can be enough time to implement RETURNING for COPY.
> I'd like to hear your opinion on that. My draft idea i
Hello,
as a continuation of my proposal expanding RETURNING syntax by
AFTER/BEFORE, there can be enough time to implement RETURNING for COPY.
I'd like to hear your opinion on that. My draft idea is:
COPY FROM ... RETURNING table_name.* -> returns all values copied to
table after all triggers invoke
15 matches
Mail list logo