This was never committed...
On Sat, Sep 13, 2014 at 4:31 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
It's likely that JB_ROOT_COUNT(val) JB_ROOT_COUNT(tmpl) should be
checked only for objects, not arrays. Also,
Peter Geoghegan p...@heroku.com writes:
This was never committed...
Yeah ... the discussion trailed off and I think we forgot to actually
commit a fix. Will go do so.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 09/15/2014 11:12 AM, Tom Lane wrote:
Or are you proposing that JSONARRAY @ JSONARRAY should work differently
from ARRAY @ ARRAY?
And no. It's a bug that jsonb array containment works differently from
regular array containment. We understand the source of the bug, ie a
mistaken
On 09/12/2014 01:33 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
However, this better become a FAQ item, because it's not necessarily the
behavior that folks used to JSON but not Postgres will expect.
No, it's a bug, not a documentation deficiency.
Hmmm? Are you proposing that
Josh Berkus j...@agliodbs.com writes:
On 09/12/2014 01:33 PM, Tom Lane wrote:
No, it's a bug, not a documentation deficiency.
Hmmm? Are you proposing that we should change how ARRAY @ ARRAY works
for non-JSON data?
No.
Or are you proposing that JSONARRAY @ JSONARRAY should work
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I'd think that we should retain it for objects; Peter's
main argument against that was that the comment would be too complicated,
but that seems a bit silly from here.
I just don't see any point to it. My argument
On Mon, Sep 15, 2014 at 2:18 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I'd think that we should retain it for objects; Peter's
main argument against that was that the comment would be too complicated,
but that
Peter Geoghegan p...@heroku.com writes:
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I'd think that we should retain it for objects; Peter's
main argument against that was that the comment would be too complicated,
but that seems a bit silly from here.
I
On Mon, Sep 15, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be that the benefit is very close to nil; that would depend a lot
on workload, so it's hard to be sure. I'd say though that the cost is
also very close to nil, in the sense that we're considering two additional
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
It's likely that JB_ROOT_COUNT(val) JB_ROOT_COUNT(tmpl) should be
checked only for objects, not arrays. Also, should JsonbDeepContains does
same fast check when it deals with nested objects?
Attached patch
Hi!
Let's consider some examples.
# select '[1,2]'::jsonb @ '[1,2,2]'::jsonb;
?column?
--
f
(1 row)
One may think it's because second jsonb array contain two 2. So, contains
takes care about count of equal elements.
# select '[1,1,2]'::jsonb @ '[1,2,2]'::jsonb;
?column?
--
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
Even more weird :)
Agreed.
The reason why jsonb contains behaves so is check in the beginning of
jsonb_contains. It makes fast check of jsonb type and elements count before
calling JsonbDeepContains.
if
Peter Geoghegan p...@heroku.com writes:
I think this is due to commit 364ddc. That removed the extra step that
had arrays sorted (and then de-duped) ahead of time, which made arrays
behave like objects at the top level. I think that this sort + de-dup
step was mischaracterized as purely a
On Fri, Sep 12, 2014 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm confused. Are you proposing to return to sort + de-dup of JSON
arrays? Surely that is completely broken. Arrays are ordered.
Sorry, my earlier remarks were premature. In fact, that alteration
only applied to existence,
On 09/12/2014 06:40 AM, Alexander Korotkov wrote:
Hi!
Let's consider some examples.
# select '[1,2]'::jsonb @ '[1,2,2]'::jsonb;
?column?
--
f
(1 row)
One may think it's because second jsonb array contain two 2. So,
contains takes care about count of equal elements.
JSONB
Peter Geoghegan p...@heroku.com writes:
On Fri, Sep 12, 2014 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm confused. Are you proposing to return to sort + de-dup of JSON
arrays? Surely that is completely broken. Arrays are ordered.
Sorry, my earlier remarks were premature. In fact,
On Fri, Sep 12, 2014 at 11:21 AM, Josh Berkus j...@agliodbs.com wrote:
# select '[1,1,2]'::jsonb @ '[1,2,2]'::jsonb;
?column?
--
t
(1 row)
But, it's not. Jsonb contains takes care only about length of array.
OK, now, that's messed up.
To be clear: I don't think that this
On 09/12/2014 11:38 AM, Peter Geoghegan wrote:
To be clear: I don't think that this example is messed up (in
isolation). I think it's the correct behavior. What I find
objectionable is the inconsistency. I believe that this is Alexander's
concern too. Alexander's first example exhibits broken
On Fri, Sep 12, 2014 at 10:38 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Sep 12, 2014 at 11:21 AM, Josh Berkus j...@agliodbs.com wrote:
# select '[1,1,2]'::jsonb @ '[1,2,2]'::jsonb;
?column?
--
t
(1 row)
But, it's not. Jsonb contains takes care only about length
Josh Berkus j...@agliodbs.com writes:
However, this better become a FAQ item, because it's not necessarily the
behavior that folks used to JSON but not Postgres will expect.
No, it's a bug, not a documentation deficiency.
regards, tom lane
--
Sent via pgsql-hackers
20 matches
Mail list logo
