Dear all,
just a little comment on this:
At least all the major DBMS support now user defined functions (UDFs) mostly written in Java, i.e. you can in fact define your own function and use it afterwards in normal SQL statements. Like this you are not that dependent on the provided functions anymore...
Andreas
On Tuesday 02 December 2003 11:14, Clive Page wrote:
> On Mon, 1 Dec 2003, John Good wrote:
> > I notice that the list of "math functions" matches PostgreSQL
> > but no other DBMS that I am aware of. For instance,
> > SQLServer, MySQL, and Informix use "log10" while Oracle
> > and PostgreSQL use "log". MySQL and PostgreSQL have
> > a "radians" function while the others don't. A different subset
> > supports "cot". It would probably be best to go with an
> > unambiguous, lowest-common-denominator approach since
> > not all systems support extension.
>
> This is something that I was also concerned about. The problem is that it
> is going to be quite hard to write astronomical code if the list of
> functions in ADQL is the rather short list supported by _every_ DBMS that
> astronomers currently use. It's worth pointint out that some sites are
> not even using a relational DBMS at all, as shown by the popularity of
> sites based on WCSTOOLS and one or two using the even more basic BROWSE.
>
> I had assumed that the ADQL document was based on the list of functions
> supported by JDBC, which in turn is said to be based on SQL92 Entry Level.
> The functions supported by JDBC 3.0 are listed at:
> http://java.sun.com/products/jdbc/driverdevs.html
>
> The JDBC list includes RADIANS and DEGREES (without which we are going to
> find life difficult) and both LOG and LOG10 but not COT.
>
> It is hard to find the SQL92 Standard on line (I think perhaps it's a
> document that you have to purchase as hard-copy), but a little googling
> found me x3h2-93-091.ps.Z from http://www.funet.fi/pub/standards/sql/
> which looks like the genuine article. I've checked the index and skimmed
> through it all (a mere 1004 pages) but failed to find a list of functions
> supported, except the obvious ones like COUNT and MAX. So maybe the
> Standard is so inadequate it's no help at all. This is very peculiar.
>
> It seems to be well known in the trade that the US National Institute of
> Standards and Technology used to be heavily involved in the SQL Standards
> process, and used to report on conformance by the major players. But some
> years ago, presumably after pressure from the large vendors whose products
> showed a lack of standards conformance, they were directed by the US
> Government to withdraw from this area. As a result, practically no
> current DBMS, and certainly none of the popular ones, conforms fully to
> any official SQL Standard. The vendors, obviously, want to lock you in to
> their product. This is very unfortunate, and we have to put up with the
> consequences.
>
>
> My own view is that the appropriate course for the VO is to settle on a
> reasonably standard set of functions, and the list of JDBC seems a good
> choice. This means, of course, that those using a DBMS which lacks these
> functions will have either have to switch to a more astronomer-friendly
> DBMS (such as Postgres) or provide a user-defined function to fill the
> gap. In the case of the RADIANS function, at least, this isn't so
> difficult, as long as your DBMS supports user-defined functions at all.
>
> > The document would also be well served by a few well-crafted
> > examples. It is often much easier to see a problem in an
> > example than in schema definitions.
>
> Agreed.
Received on 2003-12-02Z12:01:12