There are number of functions defined by ODBC 3 that we support,
but not using the exact same name or order of arguments as ODBC 3.0.
This means that some people may not choose PostgreSQL b/c it looks less
conformant. It also means that on over-simplifying tools like MySQL's
crash-me, we end up looking bad w/ rows of not-supported.
The arguments for including these seems clear.
The arguments against including these would be:
. users may have already defined their own functions w/these names (some
of them are pretty common, like MONTH(), UCASE(), etc.)
. we'd rather not do this, because we're adhering to some dreadful
standard, etc.
The first seems like a reasonable argument. Other than 'don't include by
default, but include an *.sql file w/ the distribution', are there other
ways of getting this into the server while minimizing impact on existing
apps?
(I know there was some discussion of creating portability layers, but that
seemed further off than the perl-script-that-converts-a-dump. Could
something come out of these?)
I'd be happy to spearhead a project to go through and find us some
existing wins. I think that the 5 seconds it takes to
CREATE FUNCTION LCASE(text) RETURNS TEXT AS 'begin return
lower($1); end;' LANGUAGE 'plpgsql' WITH (iscachable);
might pick us up more than a few points in the standardization/user
department.
Anyone interested?
--
Joel Burton <jburton@scw.org>
Director of Information Systems, Support Center of Washington