From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | transformations between types and languages |
Date: | 2012-05-15 20:15:38 |
Message-ID: | 1337112938.25216.10.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 to language-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) RETURNS hstore ...;
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Darren Duncan | 2012-05-16 01:50:12 | Re: transformations between types and languages |
Previous Message | Joshua Berkus | 2012-05-15 18:43:57 | Re: Strange issues with 9.2 pg_basebackup & replication |