Re: Oid registry - Mailing list pgsql-hackers

On 25.09.2012 12:19, Hitoshi Harada wrote:
> On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs<simon@2ndquadrant.com>  wrote:
>> On 24 September 2012 21:26, Andrew Dunstan<andrew@dunslane.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