Re: hstores in pl/python

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hstores in pl/python
Date: 2010-12-15 15:11:35
Message-ID: 5727.1292425895@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-12-15 15:11:54 Re: Default mode for shutdown
Previous Message Robert Haas 2010-12-15 15:08:47 Re: unlogged tables