From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | exclusion(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18835: spgist index fails to accept point with NaN |
Date: | 2025-03-07 20:08:20 |
Message-ID: | 1122078.1741378100@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> The following script:
> CREATE TABLE t(p point);
> INSERT INTO t SELECT point(g, g) FROM generate_series(1, 1000) g;
> INSERT INTO t VALUES ('(0,NaN)'::point);
> CREATE INDEX spgist_idx ON t USING spgist(p);
> triggers:
> ERROR: XX000: getQuadrant: impossible case
Yeah. There's been some past attempts to clean up our behavior
for NaNs in geometric values, but it's such a mess that not
much progress has been made. So I can't get excited about
worrying about this case in particular (especially since I don't
see any easy fix). I wonder if we shouldn't just ban NaNs in
the geometric types.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Inokuchi | 2025-03-07 20:53:03 | Re: Window Functions with identical PARTITION BY and ORDER BY clauses evaluated separately |
Previous Message | Kirill Zdornyy | 2025-03-07 20:07:45 | Error from array_agg when table has many rows |