From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
Cc: | Petr Jelinek <pjmodos(at)pjmodos(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Add JSON support |
Date: | 2010-04-07 00:00:48 |
Message-ID: | 1140.1270598448@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> writes:
> Perhaps there could be conversion functions. E.g.:
Yeah, that's what I was thinking about.
> json_to_string('"hello"') yields 'hello'
> json_to_number('3.14159') yields '3.14159' as text
> (it is up to the user to cast it to the number type s/he wants)
> json_to_bool('true') yields TRUE
> json_to_null('null') yields NULL, json_null('nonsense') fails
> string_to_json('hello') yields '"hello"' as JSON
> number_to_json(3.14159) yields '3.14159' as JSON
> bool_to_json(TRUE) yields 'true' as JSON
> null_to_json(NULL) yields 'null' as JSON (kinda useless)
The null cases seem a bit useless. What might be helpful is to
translate JSON 'null' to and from SQL NULL in each of the other
conversions, in addition to their primary capability.
I'd go with using NUMERIC as the source/result type for the numeric
conversions. Forcing people to insert explicit coercions from text
isn't going to be particularly convenient to use.
> I wonder if these could all be reduced to two generic functions, like
> json_to_value and value_to_json.
value_to_json(any) might work, but the other way could not; and it seems
better to keep some symmetry between the directions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-04-07 00:01:49 | Re: Use UNKNOWN with PL/Perl spi_prepare()? |
Previous Message | Andrew Dunstan | 2010-04-06 23:55:24 | Re: Use UNKNOWN with PL/Perl spi_prepare()? |