Ü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.
>
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 Dunst
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 requirem
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.
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, i
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 passe
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> 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 fo
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
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 (o
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.
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 real
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 got
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 langua
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 $$ ..
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
lan
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.
plperl.pass_a
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-
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 ove
18 matches
Mail list logo