Re: plperl vs. bytea

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 should probably also passed
>>> > by a byte string, yet how could Perl know that. That would imply that
>>> > user-defined types need to be able to specify how they are passed to
>>> > PLs, to *any* PL.
>>> >
>>> Yes exactly. One way could be to pass the type binary and provide
>>> a hull class for the PL/languages which then call the input/output
>>> routines on the string boundaries of the type unless overridden by
>>> user implementation. So default handling could be done in string
>>> representation of the type whatever that is and for a defined set
>>> of types every pl/language could implement special treatment like
>>> mapping to natural types.
>>>
>>> This handling can be done independently for every pl implementation
>>> since it would for the most types just move the current type treatment
>>> just a bit closer to the user code instead of doing all of it
>>> in the call handler.
>>>
>>> 2nd problem is language interface for outside of the database 
>>> scripting.
>>> Efficient and lossless type handling there would improve some
>>> situations - maybe a similar approach could be taken here.
>>>
>>>
>>
>> This seems like an elaborate piece of scaffolding for a relatively 
>> small problem.
>>
>> This does not need to be over-engineered, IMNSHO.
>
> Well could you explain where it would appear over-engineered?
> All I was proposing is to move the rather hard-coded
> type mapping to a softer approach where the language
> is able to support it.
>
> Is there any insufficience in perl which makes it harder to
> do in a clean way?
>
>

Anything that imposes extra requirements on type creators seems undesirable.

I'm not sure either that the UUID example is a very good one. This whole 
problem arose because of performance problems handling large gobs of 
data, not just anything that happens to be binary.


cheers

andrew