Re: plperl vs. bytea

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: plperl vs. bytea
Дата
Msg-id 463F24C8.5020205@dunslane.net
обсуждение исходный текст
Ответ на Re: plperl vs. bytea  (Tino Wildenhain <tino@wildenhain.de>)
Ответы Re: plperl vs. bytea  (Tino Wildenhain <tino@wildenhain.de>)
Список pgsql-hackers

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.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: temporal variants of generate_series()
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: New idea for patch tracking