Peter Geoghegan 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 changes to your sub
This was never committed...
On Sat, Sep 13, 2014 at 4:31 PM, Peter Geoghegan wrote:
> On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
> 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
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 Mon, Sep 15, 2014 at 11:29 AM, Tom Lane 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
> compare-and-branch
Peter Geoghegan writes:
> On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane 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
On Mon, Sep 15, 2014 at 2:18 PM, Peter Geoghegan wrote:
> On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane 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.
>
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane 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 against the comp
Josh Berkus 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 differently
> from A
On 09/12/2014 01:33 PM, Tom Lane wrote:
> Josh Berkus 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 we should
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
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 implements something s
Josh Berkus 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 mailing list (pgs
On Fri, Sep 12, 2014 at 10:38 PM, Peter Geoghegan wrote:
> On Fri, Sep 12, 2014 at 11:21 AM, Josh Berkus 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.
>
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 brok
On Fri, Sep 12, 2014 at 11:21 AM, Josh Berkus 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 example
Peter Geoghegan writes:
> On Fri, Sep 12, 2014 at 11:09 AM, Tom Lane 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 applie
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 ele
On Fri, Sep 12, 2014 at 11:09 AM, Tom Lane 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, not containment.
Peter Geoghegan 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 performance thin
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
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 (JB_ROOT_COUNT(val) <
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?
-
20 matches
Mail list logo
