Re: json generation enhancements

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Steve Singer <steve(at)ssinger(dot)info>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json generation enhancements
Date: 2013-02-25 00:09:53
Message-ID: 512AABD1.6020304@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 02/24/2013 06:33 PM, Craig Ringer wrote:
> On 02/24/2013 09:58 PM, Andrew Dunstan wrote:
>> Adding a cast to json for a builtin type will have no effect unless
>> you also change this code. We can relax that but my view was that we
>> should know how to generate JSON from builtin types and just do it.
> If json generation from built-in types is complete with full coverage of
> all useful types when this first ships, then I'm happy. I was only
> concerned about the BC argument "you can't add a proper json-aware cast
> from interval to json because we've already been doing it via a cast to
> text and changing the result would break existing code".
>
> That's all I'm worried about, and if that won't be an issue then I'm
> perfectly happy.
>

The code as written does not use casts except for non-builtin types.

For a builtin type you could change the way the json generators work by
using a function or cast so that the json generators saw what was
already json (which is just passed through). The trouble with this is
that if you're handling some large record and you want to do your own
conversion to json on one field it gets very messy. That's why I added
provision for honoring casts for non-builtin types - the most obvious
candidate for which is hstore, but I can imagine other types wanting to
be able to provide JSON representations.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2013-02-25 00:27:19 Re: auto_explain WAS: RFC: Timing Events
Previous Message Craig Ringer 2013-02-24 23:48:21 Re: Show type in psql SELECT