From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Daniel Farina <drfarina(at)gmail(dot)com>, Hannu Krosing <hannu(at)krosing(dot)net>, Greg Smith <greg(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Farina <dfarina(at)truviso(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Date: | 2009-11-25 05:13:04 |
Message-ID: | 1259125984.19289.20.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-11-25 05:22:12 | Re: Hot standby and removing VACUUM FULL |
Previous Message | Daniel Farina | 2009-11-25 05:12:20 | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |