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