Non-standard function names

From: Clive Page <cgp(at)star(dot)le(dot)ac(dot)uk>
To: pgsql-sql(at)postgresql(dot)org
Subject: Non-standard function names
Date: 2004-06-23 15:45:41
Message-ID: Pine.LNX.4.44L0.0406231631080.2102-100000@peneca.star.le.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

The developers of Postgres over the years are to be commended on their
support for SQL Standards, but one thing that has annoyed me for some time
is that the names of several mathematical functions are seriously
non-standard. Postgres isn't actually flouting an SQL Standard in this
area as there isn't one as far as I can discover, but the JDBC
specification includes a number of function names, and most other DBMS use
the same ones, more-or-less. I put together a small web page comparing
the function names in use in various products:
http://wiki.astrogrid.org/bin/view/Astrogrid/DBMSmathFunctions

Here one can see that Postgres actually has 6 deviations from the de-facto
JDBC standard, more than any other DBMS I examined, while MySQL comes out
as the most conformant, surprisingly.

Four of these could be fixed easily, by allowing CEILING to be a synonym
for CEIL, and similarly POW for POWER, RAND for RANDOM, and TRUNCATE for
TRUNC. Does anyone see any problems with doing that? It would surely
help people porting applications over from other DBMS.

The problems come with LN and LOG which Postgres uses for logarithms to
base e and 10 respectively: the JDBC standard uses LOG and LOG10
respectively, so that any fix would mean LOG changed its meaning. I don't
see an easy solution here; maybe both LOGE and LOG10 could be provided, at
least there would then be only one difference from the JDBC standard.

--
Clive Page
Dept of Physics & Astronomy,
University of Leicester,
Leicester, LE1 7RH, U.K.

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Stef 2004-06-23 16:07:21 ERROR: Unable to format timestamp; internal coding error
Previous Message Richard Huxton 2004-06-23 11:38:24 Re: sql