Re: WIP json generation enhancements

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP json generation enhancements
Date: 2012-11-26 16:43:47
Message-ID: 50B39C43.2080008@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/26/2012 10:55 AM, Robert Haas wrote:
> On Wed, Nov 21, 2012 at 3:16 PM, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-11-26 16:44:37 Re: 64 bit ints vs libpq-fe.h
Previous Message Tom Lane 2012-11-26 16:33:43 Re: 64 bit ints vs libpq-fe.h