On 09/25/2012 06:13 AM, Heikki Linnakangas wrote:
> 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?
No, the difficulty (or at least the first difficulty) is in having the
code recognize that it has an hstore at all. The code picks apart the
record field by field at run time and takes various actions depending on
the field's type. For any type it doesn't recognize it just outputs the
value as a string, and so that's what it does with hstore. Mostly this
is the right thing but in the hstore case it's rather sad.
>
> 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.
That's true to some extent, but names are worse, since they are schema
qualified.
cheers
andrew
