2010/12/15 Jan Urbański <wulc...@wulczer.org> > On 15/12/10 16:11, Tom Lane wrote: > > Robert Haas <robertmh...@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 ?
> > Cheers, > Jan > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- // Dmitriy.
