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 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 (or other data types for that matter).
I think that's working at the wrong level of detail, at least for
initial design.
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 similar issues.
(Even if you make the case that no other scalar types need help,
what of bytea[] and composite types containing bytea or bytea[]?)
After that we have to look at which PLs have the issue. I think
this is largely driven by what the PL's internal type system is
like, in particular does it have a datatype that is a natural
conversion target for bytea, or other types with the same issue?
(Tcl for instance once did not have 8-bit-clean strings, though
I think it does today.)
After we've got a handle on the scope of the problem we can start
to think about solutions.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
