On 15/12/10 16:11, Tom Lane wrote: > 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.
We could preassign OIDs to contrib types, but that gives the not-contrib-nor-core types the cold shoulder.
> 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.
I just had an illumination. The search path problem is the main issue, as (like you noticed), just calling I/O functions of a type should never give you anything worse than an ERROR.
> 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.
So how about just adding a text column to pg_type and a IDENTIFIER keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it pushing the argument to the extreme? Someone can change around bool and text type oids, too... And then hstore_plpython looks up the well-known identifier, sets up a RVV with the OID and everyone's happy.
How IDENTIFIER differs from name ? org.postgresql.hstore vs hstore ?