On 09/25/2012 04:26 AM, Andrew Dunstan wrote:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.
The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writes an extension that defines type A. You
want to write an extension that takes advantage of that type, but it's
difficult if you don't know the type's Oid,
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.
During the earlier to_json() discussions I already proposed a solution
to this - try
a cast to JSON type before falling back to outputting the text version.
As I understand it, this is how typecasts are supposed to be used.
In addition to being "how PostgreSQL is intended to work" it also allows
for users
to override it and have their own version of json representations for
types which have no
standard json format.
Just for the record - I'm not opposed to having a PostgreSQL OID
Registry though I think
that for anything in the backend the lookup by name should be fast enough.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
