Re: Oid registry

On Mon, Sep 24, 2012 at 8:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
>>> Could you fill the rest of us in with some technical details about why
>>> this might be necessary and what it aims to achieve?
>
>> 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.
>
> Um ... that is an entirely unconvincing use case.  We would not put any
> code into core that knows specifically about a non-core datatype, or
> at least I sure hope we'd not do such a klugy thing.  It would be far
> better to invent an extensibility scheme (plug-in of some sort) for
> record_to_json.
>

I don't think (and not hope) the core should know about external data
type, but I have certainly seen a lot of use cases where an external
project wants to know about another external data type.  Say, if plv8
wants to convert hstore into a javascript object.  It is arbitrary for
users to define such a function that accepts hstore as arguments, but
how does plv8 know the input is actually hstore?  Of course you can
look up type name conlusting SysCache and see if the type name is
"hstore", but it's expensive to do it for every function invocation,
so caching the hstore's oid in plv8 is the current workaround, which
is not truly safe because the hstore's oid may change while caching.
I can tell similar stories around array creation which needs element
type oid.  The core code can do some special stuff by using
pre-defined type or function oid macros, and I guess it is reasonable
for the external developers to hope to do such things.

Thanks,
-- 
Hitoshi Harada