On Tue, 2009-11-24 at 21:13 -0800, Jeff Davis wrote: > On Tue, 2009-11-24 at 23:44 -0500, Tom Lane wrote: > > If you do that, then there is no possibility of ever using this feature > > except with C-coded functions, which seems to me to remove most of > > whatever use-case there was. > > It fits the use case involving dblink (or dblink-like modules). > > Maybe the patch's performance should be tested with and without copying > the buffer, to see if we're losing anything significant. If we can do > almost as well copying the data and passing that as a bytea value to the > function, then I agree that would be better.
I'd make this dependent on funtion signature - if it takes bytea or text, then call it with (binary) rows - if it takes rowtype (of some hypothetic table), then resolve rows to this rowtype > I still don't see any reason to force it to be record by record though. > If the point is to push data from a table into a remote table, why > should the copied data be translated out of binary format into a record, > and then back into binary form to send to the remote system? > > Currently, the second argument to copy is a source or destination of > bytes, not records. So forcing it to deal with records is inconsistent. > > Regards, > Jeff Davis > -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
