On Wed, Dec 15, 2010 at 12:19:53AM +0100, Jan Urbański wrote: > Problem: what to do it hstore_plpython gets loaded, but hstore is not > yet loaded. hstore_plpython will want to DirectFunctionCall(hstore_in), > so loading hstore_plpython without loading hstore will result in an > ereport(ERROR, "undefined symbol hstore_in") with an errhint of "please > load hstore first". I could live with that, if no one has a better idea.
Correction: you won't get the helpful errhint, because the ERROR will be thrown when some does LOAD. And it still does not solve the problem of knowing whether it's a hstore that's been passed in to you. OK, here's another master plan: 1) hstore_plplython, when loaded, looks for a type called "hstore". If you created a "hstore" type that does not come from hstore.so, and you still load hstore_plpython, you deserve a segfault. If there is no type "hstore", it throws an ERROR. If it finds a type with that name, it creates a rendezvous variable with the name OID_plpython_parsers that points to two functions. These functions use the looked up type's I/O funcs and transform things you pass to them from and into Python objects. 2) plpython, when receiving an object with a type with the name X, takes its OID, it the OID happens not to be one of BOOLOID, FLOAT8OID etc, it does one last push of looking for a rendezvous variable OID_plpython_parsers and if it finds one, uses its parsers. If it doesn't find it, it does what it did now (cast to text and pass it to the type's I/O func). That looks almost good to me. It's mildly annoying that you can't load hstore_plpython before hstore, but I could live with that. Observe that this allows you to write a isbn_plpython module that would expose parsers for ISBN for python (or json_plpython), as well as hstore_perl, isbn_tcl and so on. It piggybacks on the rendezvous variables mechanism, and maybe in the future you could get some kind of official support in the backend for this kind of things (ie. a hash table in TopLevelContext keyed on the OIDs of the type and the language). So I'm going to try this approach now. Cheers, Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
