Peter Eisentraut wrote:
> Here is a draft design for the transforms feature, which I'd like to
> work on. The purpose of this is to allow adapting types to languages.
> The most popular case is to enable converting hstore to something useful
> like a dict or a hash in PL/Python or PL/Perl, respectively. In
> general, the type and the language don't know of each other, and neither
> need to be in core. Maybe you want to adapt PostGIS types to pygeometry
> objects in PL/Python (made up example, but you get the idea).
This is a good idea in principle.
I expect we should be able to use the same syntax both for system-defined types
and user-defined types.
I would expect, though, that in some common cases one can't avoid say having to
call hstore_to_plpython() directly, in order to disambiguate, and we may want to
provide terser syntax for using the desired TRANSFORM.
For example, if we have a Perl 5 hash, that could reasonably either map to an
hstore or to a tuple. Or a Perl 5 string with false utf8 flag could map to
either a character string or a byte string. Or a Perl 5 empty string (result of
1==0) could map to the false Boolean. Or a Perl 5 string that looks like a
number could map to either a character string or some kind of numeric. Or a
Perl 5 number 1 could map to either a numeric 1 (result of 1==1) or the true
Boolean.
Or we have to tighten the conversion rules so that things which are sometimes
equivalent and sometimes not on one side have different interpretations in the
transform.
Ideally the feature would also work not only for interfacing with PLs but also
with client languages, since conceptually its alike but just differing on who
calls who.
-- Darren Duncan
