Ühel kenal päeval, E, 2007-05-07 kell 13:57, kirjutas Andrew Dunstan:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
This does not need to be over-engineered, IMNSHO.
Well could you explain where
Added to TODO:
o Allow data to be passed in native language formats, rather
than only text
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00289$
---
Andrew
On Sun, May 06, 2007 at 08:48:28PM -0400, Tom Lane wrote:
What we've basically got here is a complaint that the default
textual-representation-based method for transmitting PL function
parameters and results is awkward and inefficient for bytea.
So the first question is whether this is really
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other user-defined
types? Say the user-defined UUID type, it should probably also passed
by a byte string, yet how could Perl know that.
Tom Lane wrote:
My GUC proposal would have made it language+type specific, but Tom
didn't like that approach.
It may indeed need to be language+type specific; what I was objecting to
was the proposal of an ad-hoc plperl-specific solution without any
consideration for other languages
Tino Wildenhain wrote:
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other user-defined
types? Say the user-defined UUID type, it should probably also passed
by a byte string, yet
Andrew Dunstan schrieb:
Tino Wildenhain wrote:
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other user-defined
types? Say the user-defined UUID type, it should probably also passed
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
Tino Wildenhain wrote:
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other
user-defined
types? Say the user-defined UUID type, it
Andrew Dunstan [EMAIL PROTECTED] writes:
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
This does not need to be over-engineered, IMNSHO.
Well could you explain where it would appear over-engineered?
Anything that imposes extra requirements on type creators seems undesirable.
I'm not
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
This does not need to be over-engineered, IMNSHO.
Well could you explain where it would appear over-engineered?
Anything that imposes extra
Peter Eisentraut wrote:
Andrew Dunstan wrote:
It's not. If we really want to tackle this root and branch without
upsetting legacy code, I think we'd need to have a way of marking
data items as binary in the grammar, e.g.
create function myfunc(myarg binary bytea) returns binary bytea
Andrew Dunstan wrote:
It's not. If we really want to tackle this root and branch without
upsetting legacy code, I think we'd need to have a way of marking
data items as binary in the grammar, e.g.
create function myfunc(myarg binary bytea) returns binary bytea
language plperl as $$ ...$$;
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
This ought to be a property of data type plus language, not a property
of a function.
Why should it?
And how would you do it in such a way that it didn't break legacy code?
My GUC proposal would have made it language+type
What we've basically got here is a complaint that the default
textual-representation-based method for transmitting PL function
parameters and results is awkward and inefficient for bytea.
So the first question is whether this is really localized to only
bytea, and if not which other types have
I have been talking with Theo some more about his recent problem with
bytea arguments and results (see recent discussion on -bugs and also
recent docs patch), what he needs is a way to have bytea (and possibly
other unknown types) passed as binary data to and from plperl. The
conversion
Andrew Dunstan [EMAIL PROTECTED] writes:
After discussing some possibilities, we decided that maybe
the best approach would be to allow a custom GUC variable that would
specify a list of types to be passed in binary form with no conversion, e.g.
plperl.pass_as_binary = 'bytea, other-type'
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
After discussing some possibilities, we decided that maybe
the best approach would be to allow a custom GUC variable that would
specify a list of types to be passed in binary form with no conversion, e.g.
17 matches
Mail list logo
