Re: Proposal: Add JSON support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal: Add JSON support
Дата
Msg-id 21867.1270569792@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal: Add JSON support  (Petr Jelinek <pjmodos@pjmodos.net>)
Ответы Re: Proposal: Add JSON support
Re: Proposal: Add JSON support
Список pgsql-hackers
Petr Jelinek <pjmodos@pjmodos.net> writes:
> Dne 6.4.2010 7:57, Joseph Adams napsal(a):
>> To me, the most logical approach is to do the obvious thing: make
>> JSON's 'null' be SQL's NULL.  For instance, SELECTing on a table with
>> NULLs in it and converting the result set to JSON would yield a
>> structure with 'null's in it.  'null'::JSON would yield NULL.  I'm not
>> sure what startling results would come of this approach, but I'm
>> guessing this would be most intuitive and useful.

> +1

I think it's a pretty bad idea for 'null'::JSON to yield NULL.  AFAIR
there is no other standard datatype for which the input converter can
yield NULL from a non-null input string, and I'm not even sure that the
InputFunctionCall protocol allows it.  (In fact a quick look indicates
that it doesn't...)

To me, what this throws into question is not so much whether JSON null
should equate to SQL NULL (it should), but whether it's sane to accept
atomic values.  If I understood the beginning of this discussion, that's
not strictly legal.  I think it would be better for strict input mode
to reject this, and permissive mode to convert it to a non-atomic value.
Thus jsonify('null') wouldn't yield NULL but a structure containing a
null.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Prepared query parsing much slower in 9.0?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Remaining Streaming Replication Open Items