On 15/12/10 15:38, Tom Lane wrote: > Jan =?utf-8?B?VXJiYcWEc2tp?= <wulc...@wulczer.org> writes: >> 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. > > No, you don't. I said upthread that relying on the name of the type was > a nonstarter, and it still is. For one thing, this sketch ignores > search path issues.
Hm. I wa assuming that if you have a type called "hstore" that's not the contrib hstore type, but you do install hstore_plpython from contrib, then you can't expect it to work. So how about this: hstore when loaded sets a rendezvous variable that points to its I/O routines, called "org.postgresql.types.hstore". hstore_plpython looks for that rendezvous variable instead of looking up the type from the catalogs, and then sets a RVV called "org.postgresql.parsers.hstore.plpython". The problem now is how plpython is supposed to know if the object it gets is the same hstore, and not some other type called hstore. What would fix it, is if the hstore module could somehow know what OID did the system assign to it, and would publish its I/O routines *and* its OID as "org.postgresql.types.hstore". hstore_plpython would then look for "org.postgresql.types.hstore" and set up "org.postgresql.parsers.OID.plpython" and plpython would look for "org.postgresql.parsers.plpython.<WHATEVER-OID-GOT-PASSED>". It almost looks like we need a unique identifier for the extension type that's known beforehand by the type writer (which "org.postgresql.types.hstore" would be) 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
