Skip site navigation (1) Skip section navigation (2)

Re: Oid registry

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-25 03:39:30
Message-ID: 3665.1348544370@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Amit KapilaDate: 2012-09-25 03:44:57
Subject: Re: Switching timeline over streaming replication
Previous:From: Tom LaneDate: 2012-09-25 03:21:23
Subject: Re: Oid registry

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group