I wrote:
> Heikki Linnakangas writes:
>> 2. This was the same before this patch, but:
>> postgres=# select '{{1}}'::int[];
>> ERROR: number of array dimensions (7) exceeds the maximum allowed (6)
>> LINE 1: select '{{1}}'::int[];
>> ^
>> The error message isn't
Heikki Linnakangas writes:
> On 09/11/2023 18:57, Tom Lane wrote:
>> Barring objections, I think v12 is committable.
> Looks good to me. Just two little things caught my eye:
> 1.
> The function comments in ReadArrayDimensions and ReadArrayStr don't make
> it clear that these arrays need to be
On 09/11/2023 18:57, Tom Lane wrote:
After further thought I concluded that this area is worth spending
a little more code for. If we have input like '{foo"bar"}' or
'{"foo"bar}' or '{"foo""bar"}', what it most likely means is that
the user misunderstood the quoting rules. A message like
I wrote:
> This comes out when you write something like '{foo"bar"}', and I'd
> say the choice of message is not great. On the other hand, it's
> consistent with what you get from '{"foo""bar"}', and if we wanted
> to change that too then some tweaking of the state machine in
> ReadArrayStr would
Alexander Lakhin writes:
> Thank you for the update! I haven't looked into the code, just did manual
> testing and rechecked commands given in the arrays documentation ([1]).
> Everything works correctly, except for one minor difference:
> INSERT INTO sal_emp
> VALUES ('Bill',
>
Hello Tom,
08.11.2023 02:52, Tom Lane wrote:
Comments?
Thank you for the update! I haven't looked into the code, just did manual
testing and rechecked commands given in the arrays documentation ([1]).
Everything works correctly, except for one minor difference:
INSERT INTO sal_emp
VALUES
I got back to looking at this today (sorry for delay), and did a pass
of code review. I think we are getting pretty close to something
committable. The one loose end IMO is this bit in ReadArrayToken:
+case '"':
+
+/*
+ * XXX "Unexpected %c character"
rebase after commit
(https://git.postgresql.org/cgit/postgresql.git/commit/?id=611806cd726fc92989ac918eac48fd8d684869c7)
From d37081ba00743585dae35c70e293ce2385201c9c Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Sat, 8 Jul 2023 22:19:48 +0300
Subject: [PATCH v9 5/7] Determine array
On Thu, Sep 14, 2023 at 2:00 PM Alexander Lakhin wrote:
>
>
> I didn't mean to remove the prefix "array_in-", but in fact I was confused
> by the "{function_name}-" syntax, and now when I've looked at it closely, I
> see that that syntax was quite popular ("date_in- ", "single_decode- ", ...)
>
13.09.2023 11:55, jian he wrote:
2) CPPFLAGS="-DARRAYDEBUG" ./configure ... breaks "make check", maybe change
elog(NOTICE) to elog(DEBUG1)?
2a) a message logged there lacks some delimiter before "lBound info":
NOTICE: array_in- ndim 1 ( 3 -1 -1 -1 -1 -1lBound info 1 1 1 1 1 1) for
On Wed, Sep 13, 2023 at 2:00 PM Alexander Lakhin wrote:
>
>
> Now I see only a few wrinkles.
> 1) A minor asymmetry in providing details appeared:
> select E'{"a"a}'::text[];
> ERROR: malformed array literal: "{"a"a}"
> LINE 1: select E'{"a"a}'::text[];
> ^
> DETAIL: Unexpected
12.09.2023 11:45, jian he wrote:
On Mon, Sep 11, 2023 at 8:00 PM Alexander Lakhin wrote:
I can confirm that all those anomalies are fixed now.
But new version brings a warning when compiled with gcc:
arrayfuncs.c:659:9: warning: variable 'prev_tok' is uninitialized when used
here
On Mon, Sep 11, 2023 at 8:00 PM Alexander Lakhin wrote:
>
> I can confirm that all those anomalies are fixed now.
> But new version brings a warning when compiled with gcc:
> arrayfuncs.c:659:9: warning: variable 'prev_tok' is uninitialized when used
> here [-Wuninitialized]
>
11.09.2023 08:26, jian he wrote:
hi.
Thanks for reviewing it.
DETAIL: Unexpected end of input.
In many cases, ending errors will happen, so I consolidate it.
SELECT '{{},}'::text[];
solved by tracking current token type and previous token type.
select '{\{}'::text[];
solved by update
On Sun, Sep 10, 2023 at 6:00 PM Alexander Lakhin wrote:
> 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
Hello Jian,
05.09.2023 02:53, jian he wrote:
On Mon, Sep 4, 2023 at 8:00 AM jian he 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
On Mon, Sep 4, 2023 at 8:00 AM jian he 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
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,
hi.
based on Heikki v3.
I made some changes:
array_in: dim[6] all initialize with -1, lBound[6] all initialize with 1.
if ReadArrayDimensions called, then corresponding dimension lBound
will replace the initialized default 1 value.
ReadArrayStr, since array_in main function initialized dim array,
On Sun, Jul 9, 2023 at 3:38 AM Heikki Linnakangas wrote:
>
> On 08/07/2023 19:08, Tom Lane wrote:
> > I wrote:
> >> So I end up with the attached. I went ahead and dropped
> >> ArrayGetOffset0() as part of 0001, and I split 0002 into two patches
> >> where the new 0002 avoids re-indenting any
On 08/07/2023 22:49, Tom Lane wrote:
BTW, what's your opinion of allowing "[1:0]={}" ? Although that was
my proposal to begin with, I'm having second thoughts about it now.
The main reason is that the input transformation would be lossy,
eg "[1:0]={}" and "[101:100]={}" would give the same
Heikki Linnakangas writes:
> On 08/07/2023 19:08, Tom Lane wrote:
>> That got sideswiped by ae6d06f09, so here's a trivial rebase to
>> pacify the cfbot.
> Something's wrong with your attachments.
Yeah, I forgot to run mhbuild :-(
> I spent some time today refactoring it for readability and
On 08/07/2023 19:08, Tom Lane wrote:
I wrote:
So I end up with the attached. I went ahead and dropped
ArrayGetOffset0() as part of 0001, and I split 0002 into two patches
where the new 0002 avoids re-indenting any existing code in order
to ease review, and then 0003 is just a mechanical
I wrote:
> That got sideswiped by ae6d06f09, so here's a trivial rebase to
> pacify the cfbot.
Sigh, this time with patch.
regards, tom lane
From 63ee707f6aa38043c0211c0c4a124fa5fe2ad016 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sat, 8 Jul 2023 11:55:56 -0400
I wrote:
> So I end up with the attached. I went ahead and dropped
> ArrayGetOffset0() as part of 0001, and I split 0002 into two patches
> where the new 0002 avoids re-indenting any existing code in order
> to ease review, and then 0003 is just a mechanical application
> of pgindent.
That got
Nikhil Benesch writes:
> I spotted a few opportunities for further reducing state tracked by
> `ArrayCount`. You may not find all of these suggestions to be
> worthwhile.
I found some time today to look at these points.
> 1) `in_quotes` appears to be wholly redundant with `parse_state ==
>
based on Nikhil Benesch idea.
The attached diff is based on
v1-0002-Rewrite-ArrayCount-to-make-dimensionality-checks.patch.
diff compare v1-0002:
select '{{1,{2}},{2,3}}'::text[];
ERROR: malformed array literal: "{{1,{2}},{2,3}}"
LINE 1: select '{{1,{2}},{2,3}}'::text[];
^
On Mon, Jun 5, 2023 at 9:48 AM Nikhil Benesch wrote:
>
> I took a look at 0002 because I attempted a similar but more surgical
> fix in [0].
>
> I spotted a few opportunities for further reducing state tracked by
> `ArrayCount`. You may not find all of these suggestions to be
> worthwhile.
I
Nikhil Benesch writes:
> I took a look at 0002 because I attempted a similar but more surgical
> fix in [0].
> I spotted a few opportunities for further reducing state tracked by
> `ArrayCount`.
Wow, thanks for looking! I've not run these suggestions to ground
(and won't have time for a few
I took a look at 0002 because I attempted a similar but more surgical
fix in [0].
I spotted a few opportunities for further reducing state tracked by
`ArrayCount`. You may not find all of these suggestions to be
worthwhile.
1) `in_quotes` appears to be wholly redundant with `parse_state ==
09.05.2023 06:06, Tom Lane wrote:
Alexander Lakhin writes:
The only thing that confused me, is the error message (it's not new, too):
select '{{1}}'::int[];
or even:
select '{{'::int[];
ERROR: number of array dimensions (7) exceeds the maximum allowed (6)
Yeah, I
Alexander Lakhin writes:
> The only thing that confused me, is the error message (it's not new, too):
> select '{{1}}'::int[];
> or even:
> select '{{'::int[];
> ERROR: number of array dimensions (7) exceeds the maximum allowed (6)
Yeah, I didn't touch that, but it's
02.05.2023 18:41, Tom Lane wrote:
So, here's a rewrite.
Although I view this as a bug fix, AFAICT the only effects are to
accept input that should be rejected. So again I don't advocate
back-patching. But should we sneak it into v16, or wait for v17?
I've tested the patch from a user
On Tue, May 02, 2023 at 11:41:27AM -0400, Tom Lane wrote:
> It looks like back in the dim mists of the
> Berkeley era, there was an intentional attempt to allow
> non-rectangular array input, with the missing elements automatically
> filled out as NULLs. Since that was undocumented, we concluded
This is in response to Alexander's observation at [1], but I'm
starting a fresh thread to keep this patch separate from the plperl
fixes in the cfbot's eyes.
Alexander Lakhin writes:
> I continue watching the array handling bugs dancing Sirtaki too. Now it's
> another asymmetry:
> select
35 matches
Mail list logo
