Re: Proposal: Add JSON support

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: Add JSON support
Date: 2010-03-29 12:06:38
Message-ID: 4BB097CE.7040700@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> I feel pretty strongly that the data should be stored in the database
> in the format in which it will be returned to the user - any
> conversion which is necessary should happen on the way in. I am not
> 100% sure to what extent we should attempt to canonicalize the input
> and to what extend we should simply store it in whichever way the user
> chooses to provide it.
>
>

ISTM that implies that, with a possible exception when the server
encoding is utf8, you would have to \u escape the data on the way in
fairly pessimistically.

I'd be inclined to say we should store and validate it exactly as the
client gives it to us (converted to the server encoding, as it would be,
of course). In practice that would mean that for non-utf8 databases the
client would need to \u escape it. I suspect most uses of this would be
in utf8-encoded databases anyway.

I also think we should provide a function to do the escaping, so users
could do something like:

insert into foo (myjson) values (json_escape('some jason text here'));

I also thought about a switch to turn on \u escaping on output - that
might be useful for pg_dump for instance.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2010-03-29 13:35:42 Re: Problems with variable cursorname in ecpg
Previous Message Michael Meskes 2010-03-29 11:34:35 Problems with variable cursorname in ecpg