Re: hstores in pl/python - Mailing list pgsql-hackers

From Tom Lane
Subject Re: hstores in pl/python
Date
Msg-id 5727.1292425895@sss.pgh.pa.us
Whole thread Raw
In response to Re: hstores in pl/python  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: hstores in pl/python  (Jan Urbański <wulczer@wulczer.org>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I was asking what would satisfy you as regards a reliable way to
> identify a type, not what you think we should do about this particular
> proposal.

Okay: a preassigned OID is safe.  I haven't seen any other safe
proposals.  Relying on a non-reserved name is transparently unsafe.

[ thinks for awhile ... ]  You could imagine having the hstore module
set up a rendezvous variable containing the OIDs of its type, its
I/O functions, and anything else plpython might need to know.  Except
that the hstore C code doesn't know those OIDs either, at least not
when first loaded.  There's also the problem that you don't really want
plpython's behavior suddenly changing when hstore happens to get loaded
or first used.

Another possibility is that you make the user tell you the
fully-qualified name of the type:
plpython.use_hstore = 'public.hstore'

Such a GUC would also fix the backwards compatibility issues, since
in the absence of a setting you'd continue to use the old behavior.
But other than that configurability angle, this seems pretty ugly.
Also you'd have to think about protecting yourself against a bad
setting, ie the GUC specifies a type that's not hstore.  That might
not be a big problem though, as long as you aren't directly messing
with the type's representation but just calling its I/O functions.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: unlogged tables
Next
From: Alvaro Herrera
Date:
Subject: Re: Default mode for shutdown