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
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 |