Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
От | Jeff Davis |
---|---|
Тема | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Дата | |
Msg-id | 1259130221.19289.109.camel@jdavis обсуждение исходный текст |
Ответ на | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO
FUNCTION
Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Список | 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
В списке pgsql-hackers по дате отправления: