transformations between types and languages
От | Peter Eisentraut |
---|---|
Тема | transformations between types and languages |
Дата | |
Msg-id | 1337112938.25216.10.camel@vanquo.pezone.net обсуждение исходный текст |
Ответы |
Re: transformations between types and languages
Re: transformations between types and languages Re: transformations between types and languages |
Список | pgsql-hackers |
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). What we basically need is a system catalog like this: type -- the type to which this applies, e.g. hstore lang -- e.g. plperl fromsql -- function to convert from SQL tolanguage-specific tosql -- function to convert from language-specific to SQL fromsql takes one argument of the respective type and returns internal. tosql is the other way around. It's the responsibility of the language handler to look up this information and use it. The "internal" argument or return value will be something specific to the language implementation and will likely be under the memory management of the language handler. The reason I call this transforms is that there is an SQL feature called transforms. This was originally intended to allow adapting user-defined types to client side languages, so it's about the same concept. If there are concerns about overloading a standard feature like that, we can change the name, but I fear there aren't going to be that many handy synonyms available in the transform/translate/convert space. Syntax examples: CREATE LANGUAGE plpythonu ...; CREATE TYPE hstore ...; CREATE FUNCTION hstore_to_plpython(hstore) RETURNS internal ...; CREATE FUNCTION plpython_to_hstore(internal) RETURNShstore ...; The actual implementation of these will look like the existing PLyObject_ToBytea() and all those, except that instead of a hard-coded switch statement, they will be selected through a system catalog. CREATE TRANSFORM FOR hstore LANGUAGE plpythonu ( FROM SQL WITH hstore_to_plpython, TO SQL WITH plpython_to_hstore); If you have a plfoo/plfoou pair, you need to issue two statements like that. But maybe we could offer the syntax LANGUAGE plperl, plperlu. In practice, you would wrap this up in an extension which would depend on hstore and plpython.
В списке pgsql-hackers по дате отправления: