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

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Daniel Farina <drfarina@gmail.com>, Hannu Krosing <hannu@krosing.net>, Greg Smith <greg@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Daniel Farina <dfarina@truviso.com>, pgsql-hackers@postgresql.org
Date: 2009-11-25T06:23:41Z
Lists: pgsql-hackers
On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
> I believe so using an "internal" minimalize necessary changes in COPY
> implementation. Using a funcapi needs more work inside COPY -  you
> have to take some functionality from COPY to stream functions.
> Probably the most slow operations is parsing - calling a input
> functions. This is called once every where. Second slow operation is
> reading from network - it is same. So I don't see too much reasons,
> why non internal implementation have to be significant slower than
> your actual implementation. I am sure, so it needs more work.

I apologize, but I don't understand what you're saying. Can you please
restate with some examples?

It seems like you're advocating that we move records from a table into a
function using COPY. But that's not what COPY normally does: COPY
normally translates records to bytes or bytes to records.

Moving records from a table to a function can be done with:
  SELECT myfunc(mytable) FROM mytable;
already. The only problem is if you want initialization/destruction. But
I'm not convinced that COPY is the best tool to provide that.

Moving records from a function to a table can be done with:
  INSERT INTO mytable SELECT * FROM myfunc();
And that already works fine.

So what use case are you concerned about?

Regards,
	Jeff Davis