2009/11/25 Daniel Farina <drfarina@gmail.com>:
> On Tue, Nov 24, 2009 at 10:23 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> 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.
>
> Perhaps what we want is pluggable transformation functions that can
> format the row any way that is desired, with the current behavior
> being some default. Putting COPY TO FUNCTION as submitted aside, what
> about something like this:
>
> COPY foo TO '/tmp/foo' USING postgres_builtin_formatter(csv = true);
>
> This is something completely different than what was submitted, so in
> some aspect:
>
> COPY foo TO FUNCTION dblink_send_row USING
> postgres_builtin_formatter(binary = true);
>
> Would compose the two features...
>
yes - it is two features - and should be solved independently
Pavel
> (Again, very, very far from a real syntax suggestion)
>
> fdr
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
