Re: Oid registry

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-25 21:58:47
Message-ID: 565.1348610327@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 9/24/12 10:26 PM, Andrew Dunstan 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 think the fix there is that the type supplies a "to JSON" function as
> part of its type definition (just like input and output functions). "to
> XML" would also be useful. Most types wouldn't need them and default to
> string output.

Yes ... but I really don't want to go down the path of treating those as
new type properties; it doesn't scale. (And please don't tell me that
JSON is the last word in container types and there will never be
requests for any more of these.)

Can we define these functions as being the cast-from-foo-to-json and
cast-from-foo-to-xml functions? That would let us use the existing cast
infrastructure to manage them.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-09-25 22:00:11 Re: Oid registry
Previous Message Peter Eisentraut 2012-09-25 21:54:28 Re: Oid registry