Re: BUG #11207: empty path will segfault jsonb #>
От | Tom Lane |
---|---|
Тема | Re: BUG #11207: empty path will segfault jsonb #> |
Дата | |
Msg-id | 26461.1408497576@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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 |
I wrote: > justin.vanwinkle@gmail.com writes: >> select '{"a": {"b":{"c": "foo"}}}'::jsonb #> '{}'; >> [ dumps core ] > Hm. It's not immediately obvious to me what this should be defined to do; > should it throw an error, or return the complete LHS object, or perhaps > return a NULL? But the author of get_jsonb_path_all() evidently didn't > consider the case. It occurred to me to check what the pre-existing JSON-type code does with this case, and I find it returns NULL. So there's certainly an argument to be made for following that precedent and calling it a day. However, on reflection it seems to me that this behavior is entirely nonsensical, and the sane thing to do is to return the given json or jsonb input. Surely #> with a K-element path ought to act the same as K invocations of the -> operator ... and zero invocations would result in just having the original input object, no? So I propose that we fix both operators to return the input object in this case, and release-note the change in behavior from 9.3. BTW, the same argument would suggest that if the array contains null elements, the right thing to do is return NULL, not throw an error as the current code does. You would get a NULL if you passed a NULL RHS to ->, because it's strict. regards, tom lane
В списке pgsql-bugs по дате отправления: