2009/8/18 Peter Eisentraut <peter_e@gmx.net>:
> On mån, 2009-08-17 at 10:42 -0400, Tom Lane wrote:
>> For the record, I think this entire patch is a bad idea. PLs should not
>> be so much in bed with the internal representation of datatypes. To
>> take just one example, this *will* break when/if we change text to carry
>> some internal locale indicator. There has been absolutely zero evidence
>> presented to justify that there's a need to break abstraction to gain
>> performance in this area.
>
I thing, so communication based on text type is bad. Maybe we should
to use binary communication based on send and recv function? It's
should be better and maybe stable than direct transfer - but maybe
little bit slower.
> The motivation for this patch has nothing to do with performance. The
> point is to pass data types into and out of PL/Python sensibly. In
> particular, passing bytea into and out of PL/Python is currently
> completely broken, in the sense that what you get in Python is not a
> byte string that you can process sensibly.
>
I thing so bytea should be very well optimized. You can expect, so
there be moved bigger block of data.
regards
Pavel
> We could argue that peeking inside the internal representation of data
> types might be inappropriate. In which case the solution would be to
> run the data through the data type output function and have PL/Python
> parse that back in. That would just be a localized change in the patch,
> however. (It might be less than ideal for passing float types,
> perhaps.) We do, however, expose a data types binary format through the
> binary protocol, so perhaps we should be using the send/recv functions
> instead of input/output. Which would require hardcoding the bytea
> binary format, at least. Either of these solutions would probably solve
> the domains problem, though.
>
> Note also that we have historically broken the bytea text format twice
> as often as the bytea binary format. ;-)
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
