From: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Theo Schlossnagle <jesus(at)omniti(dot)com> |
Subject: | Re: plperl vs. bytea |
Date: | 2007-05-07 16:09:17 |
Message-ID: | 463F4F2D.4040705@wildenhain.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Regards
Tino
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-05-07 17:00:02 | Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
Previous Message | Jim Nasby | 2007-05-07 16:00:09 | Re: psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory |