From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Cleaning up array_in() |
Date: | 2023-09-10 10:00:00 |
Message-ID: | 81c6363b-e0d0-c65a-8c91-bb9bfb007672@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Jian,
05.09.2023 02:53, jian he wrote:
> On Mon, Sep 4, 2023 at 8:00 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>> hi.
>> attached v4.
>> v4, 0001 to 0005 is the same as v3 in
>> https://www.postgresql.org/message-id/5859ce4e-2be4-92b0-c85c-e1e24eab57c6%40iki.fi
>>
>> v4-0006 doing some modifications to address the corner case mentioned
>> in the previous thread (like select '{{1,},{1},}'::text[]).
>> also fixed all these FIXME, Heikki mentioned in the code.
>>
>> v4-0007 refactor ReadDimensionInt. to make the array dimension bound
>> variables within the INT_MIN and INT_MAX. so it will make select
>> '[21474836488:21474836489]={1,2}'::int[]; fail.
>
> attached, same as v4, but delete unused variable {nitems_according_to_dims}.
Please look at the differences, I've observed with the latest patches
applied, old vs new behavior:
Case 1:
SELECT '{1,'::integer[];
ERROR: malformed array literal: "{1,"
LINE 1: SELECT '{1,'::integer[];
^
DETAIL: Unexpected end of input.
vs
ERROR: malformed array literal: "{1,"
LINE 1: SELECT '{1,'::integer[];
^
(no DETAIL)
Case 2:
SELECT '{{},}'::text[];
ERROR: malformed array literal: "{{},}"
LINE 1: SELECT '{{},}'::text[];
^
DETAIL: Unexpected "}" character
vs
text
------
{}
(1 row)
Case 3:
select '{\{}'::text[];
text
-------
{"{"}
(1 row)
vs
text
------
{""}
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-09-10 16:35:10 | Re: Inefficiency in parallel pg_restore with many tables |
Previous Message | David Rowley | 2023-09-10 09:07:53 | Re: Surely this code in setrefs.c is wrong? |