This sounds good. Would these exist in ODBC or in the backend? My
understanding is that these are best done in ODBC.
>
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
