From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Cleaning up array_in() |
Date: | 2023-07-08 20:03:47 |
Message-ID: | 01a01e88-de7b-d4b9-175a-a8699729243c@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 results, which
> seems a little ugly.
Hmm, yeah, that would feel wrong if you did something like this:
select ('[2:1]={}'::text[]) || '{x}'::text[];
and expected it to return '[2:2]={x}'.
I guess we could allow "[1:0]={}" as a special case, but not
"[101:100]={}", but that would be weird too.
> Given the lack of field complaints, maybe we should leave that
> alone.
+1 to leave it alone. It's a little weird either way, so better to stay
put. We can revisit it later if we want to, but I wouldn't want to go
back and forth on it.
--
Heikki Linnakangas
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-07-08 20:33:54 | Re: DecodeInterval fixes |
Previous Message | Tom Lane | 2023-07-08 19:49:31 | Re: Cleaning up array_in() |