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  (Darren Duncan <darren@darrenduncan.net>)
Re: transformations between types and languages  (Robert Haas <robertmhaas@gmail.com>)
Re: transformations between types and languages  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joshua Berkus
Дата:
Сообщение: Re: Strange issues with 9.2 pg_basebackup & replication
Следующее
От: Darren Duncan
Дата:
Сообщение: Re: transformations between types and languages