Re: BUG #11207: empty path will segfault jsonb #>

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: BUG #11207: empty path will segfault jsonb #>
Дата
Msg-id CAM3SWZT8kJFHFOa2V4dp-yR18=RgHJZf8aXMk=O3xd9++FFOew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #11207: empty path will segfault jsonb #>  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #11207: empty path will segfault jsonb #>  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Wed, Aug 20, 2014 at 11:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Is there a reason for these to behave inconsistently, and if not, which
> behavior should we standardize on?  Considering that you get NULL not an
> error for extracting a nonexistent element from an object, I think there
> is some case to be made for saying that returning NULL is the more
> convenient behavior.  Of course one can also argue for wanting this
> operator to throw errors if the JSON structure doesn't match the
> operation, but it seems like we've chosen to prefer being lax.

I discussed this very issue with Andrew during development (I think
that this happened to occur in private). My view was that since users
will frequently use -> within expression indexes, it's best to have it
return NULL for non-objects, rather than make them worry about the
case where it'll be rejected, which is rather contrary to the spirit
of jsonb (at least as a default behavior). Andrew argued it was
preferable to stick to the historic behavior of json operators. IMV,
we should have both operators return NULL. They should be consistent,
which implies changing the behavior of the existing json variants too,
but I don't think that's a big problem.

Note that the documentation briefly draws attention to this issue, in
a comment in the expression index example.

--
Peter Geoghegan

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #11207: empty path will segfault jsonb #>
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #11207: empty path will segfault jsonb #>