From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Martin L(dot) Buchanan" <martinlbuchanan(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: integer square root function proposed |
Date: | 2022-12-18 04:20:45 |
Message-ID: | 157202.1671337245@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Martin L. Buchanan" <martinlbuchanan(at)gmail(dot)com> writes:
> Reading the documentation I found no built-in function for integer square
> root, requiring a sequence of:
> floor(sqrt(foo))::integer
> to go from an integer to the integer square root as an integer.
I'm a little down on this idea, mainly because I doubt there is any
principled argument as to whether the rounding ought to be down, up,
or to nearest. Specific applications probably want a specific one
of those, but how likely is it that a built-in choice would satisfy
many users?
I'm not buying the performance angle too much either. Even granting
that your platform has an integer square root instruction that's faster
than its floating-point one, and that we can get at that from C, the
difference would likely be swamped by the overhead of the SQL function
call.
> (And with infinities and NaNs processed as described in
> 8.1 Numeric Types).
Our integers do not have infinities, nor NaNs.
Anyway, I don't mean to slam the door on this idea completely,
but I think you need to make a much better-supported argument
for it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Boussekey | 2022-12-18 11:01:52 | Re: Autovacuum on sys tables |
Previous Message | Rob Sargent | 2022-12-18 03:56:16 | Re: integer square root function proposed |