Re: WIP json generation enhancements - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: WIP json generation enhancements
Date
Msg-id 50B39C43.2080008@dunslane.net
Whole thread Raw
In response to Re: WIP json generation enhancements  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP json generation enhancements  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 11/26/2012 10:55 AM, Robert Haas wrote:
> On Wed, Nov 21, 2012 at 3:16 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Non-builtin types are now searched for a cast to json, and if it exists it
>> is used instead of the type's text representation. I didn't add a special
>> type to look for a cast to, as was discussed before, as it seemed a bit
>> funky and unnecessary. It can easily be added, but I'm still not convinced
>> it's a good idea. Note that this is only done for types that aren't builtin
>> - we know how to turn all of those into json without needing to look for a
>> cast.
> The place where I fear this will cause problems is with non-core
> text-like datatypes, such as citext.  For example, I wonder if
> creating a cast from citext to json - which seems like a sensible
> thing to want to do for other reasons - changes the semantics of this
> function when applied to citext objects.
>


I don't understand why you would want to create such a cast. If the cast 
doesn't exist it will do exactly what it does now, i.e. use the type's 
output function and then json quote and escape it, which in the case of 
citext is the Right Thing (tm):
   andrew=# select to_json('foo"bar'::citext);      to_json   ------------     "foo\"bar"


cheers

andrew





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 64 bit ints vs libpq-fe.h
Next
From: Magnus Hagander
Date:
Subject: Re: 64 bit ints vs libpq-fe.h