| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | sbjesse(at)gmail(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16560: Strange behavior with polygon and NaN |
| Date: | 2020-07-29 18:48:28 |
| Message-ID: | 1328238.1596048508@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:
> While working with Chris Hajas on merging Postgres 12 with Greenplum
> Database we stumbled upon the following strange behavior in the geometry
> type polygon:
Yeah, I'd imagine that none of the geometric operators/functions take
any thought for NaNs; if they behave sanely it's purely accidental.
Not really sure what we'd do about that --- operators returning
boolean, for instance, don't have a great way to handle it. (I doubt
returning NULL would be nice.) Going forward it might be best
to disallow NaNs in geometric values, perhaps?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-07-29 23:38:59 | BUG #16561: timestamp with time zone microseconds inconsistently recorded correctly and incorrectly |
| Previous Message | PG Bug reporting form | 2020-07-29 17:47:18 | BUG #16560: Strange behavior with polygon and NaN |