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 #>
|
Список | 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 по дате отправления: