Re: hstores in pl/python

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: hstores in pl/python
Дата
Msg-id 5727.1292425895@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: hstores in pl/python  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: hstores in pl/python  (Jan Urbański <wulczer@wulczer.org>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: unlogged tables
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Default mode for shutdown