On Wed, May 08, 2013 at 01:16:14PM -0400, Tom Lane wrote: > Heikki Linnakangas <hlinnakan...@vmware.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,
With utmost respect, that is one of several use cases, and any change would need to keep that use case unburdened. A sometimes overlapping set of use cases move data in and out of the database in a simple manner. In some of these, people might wish to trade some performance for the feature. A particular example would be one where there are several tables to be loaded, some with generated columns that the future ones would depend on. Yes, it's possible (kinda) to do this with the FDW machinery, but the burden is much higher as it requires DDL permission in general each time. > so weighing it down with processing options seems like a pretty > dubious idea even if the implementation were easy. Totally agreed that the "fast load/unload" code path must not be affected by any such changes. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
