Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

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