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.
My recollection of the PGCon discussion is that people wanted to allow
client-side code to hard-wire type OIDs for add-on types, in more or
less the same way that things like JDBC know that "25" is "text".
That's not unreasonable, since the alternatives are complicated and
not all that reliable. I'm not sure the usage applies to anything
except data types though, so at least for starters I'd only want to
accept reservations of OIDs for data types.
regards, tom lane
