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-27 19:38:09
Message-ID: 50B516A1.3050000@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/26/2012 12:31 PM, Robert Haas wrote:
> On Mon, Nov 26, 2012 at 11:43 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> 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"
> I'm not sure either, but setting up a system where seemingly innocuous
> actions can in fact have surprising and not-easily-fixable
> consequences in other parts of the system doesn't seem like good
> design to me. Of course, maybe I'm misunderstanding what will happen;
> I haven't actually tested it myself.
>

I'm all for caution, but the argument here seems a bit nebulous. We
could create a sort of auxiliary type, as has been previously suggested,
that would be in all respects the same as the json type except that it
would be the target of the casts that would be used in to_json() and
friends. But, that's a darned ugly thing to have to do, so I'd want a
good concrete reason for doing it. Right now I'm having a hard time
envisioning a problem that could be caused by just using the
straightforward solution that's in my latest patch.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-27 19:41:34 Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Previous Message Tom Lane 2012-11-27 19:26:14 Re: MySQL search query is not executing in Postgres DB