On 15/12/10 15:38, Tom Lane wrote:
> Jan Urbański <wulczer@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
