Re: Oid registry

On 25.09.2012 12:19, Hitoshi Harada wrote:
> On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>> On 24 September 2012 21:26, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>> Well, an obvious case is how record_to_json handles fields. If it knows
>>> nothing about the type all it can do is output the string value. That
>>> doesn't work well for types such as hstore. If it could reliably recognize a
>>> field as an hstore it might well be able to do lots better.

I'm not at all familiar with record_to_json or the json datatype, but
wouldn't it be appropriate to create a cast from hstore to json to
handle that case?

That brings us to another question: should the cast be part of the
hstore extension, or json? (json is built-in, but imagine for a moment
that it was an extension, too, so that there was a choice). IIRC someone
started a discussion on that recently on pgsql-hackers, but I don't
think there was any conclusion on that.

>> I think we're missing something in the discussion here.
>>
>> Why can't you find out the oid of the type by looking it up by name?
>> That mechanism is used throughout postgres already and seems to work
>> just fine.
>
> Sure, but how do you know the type named "hstore" is what you know as
> hstore? We don't have a global consensus a specific type name means
> exactly what everyone thinks it is.

If you create a type called "hstore" that isn't the one in
contrib/hstore, you're just asking for trouble. Having a central
registry of assigned oid numbers doesn't really make that problem go
away either; you could still assign one of the registered oids for a
different datatype if you wanted to.

So whether you rely on the oid or type name, your code needs to behave
sanely, even if the datatype doesn't behave the way you'd expect. At a
minimum, there needs to be sanity checks so that you don't crash, and
give a meaningful error message. Beyond that, I think it's the user
responsibility to not confuse things by using well-known datatype names
like "hstore" for something else.

Here's another thought: imagine that someone creates a datatype that's
more or less compatible with contrib/hstore, but the internal
implementation is different. Would you call that hstore? Would you use
the same assigned oid for it? If you have some other extension that
knows about hstore, and treats it specially, would you want the new
datatype to be treated specially too?

And what about domains? If you have code that knows the oid of hstore
and gives it special treatment, should domains over hstore also be given
special treatment?

- Heikki