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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to