Re: ODBC 3.0 functions (UCASE, LCASE, etc.)

OK, I am quoting at the top because I don't want to delete any of this.

I think this is a great idea. In final form, it would be good to have a
layer pre-parse the query string and rewrite Oracle-isms or MySQL-isms
before they get to the parser, but as a first step, have a plug-in that
would add this functionality is great. You could have it as an sql file
that can be loaded right into a database. We already added Oracle
functions for things we already didn't have. As these are synomyms,
they would be best as loadable modules so they were not all in there at
once.

> >
> > This sounds good. Would these exist in ODBC or in the backend? My
> > understanding is that these are best done in ODBC.
>
> It's not so much an ODBC problem *per se*, but, rather, that many
> databases offer 'functions' (some from standards, some made up) that we
> don't have. (The ODBC specs just happen to recommend a large slew of
> them.)
>
> I'd think these would have to be backend functions, but probably best not
> actually in the backend source.
>
> Since we can create functions easily, and since few of these things are
> actually new features, but re-named/re-ordered functions we already have,
> it wouldn't seem too onerous to make wrappers around these, or hook some
> of these in as aliases for existing functions/types.
>
> Things like:
>
> - aliasing int to mediumint
> - alias textcat to concat
> - iif( condition, true_expr, false_expr )
> - first(), last() aggregates
> - std() as an alias for stddev()
>
> Yes, some of these *are* ugly, non-standard forms used by other databases.
> Read on for why I still think it could be a good idea.
>
> Some things we have (like existing odbc.sql file in src/interfaces/odbc),
> or in contrib/ (like soundex) are probably missed by many users. (And,
> although this is probably intentional, are left off of MySQL's crash-me).
>
> Perhaps a useful form would be a folder of function wrappers, group by
> 'competitor':
>
> oracle.sql
> mysql.sql
> access.sql
> odbc.sql
>
> which would contain the wrappers functions for these systems. Of course,
> we can't mimic *everything* (at least not in plpgsql functions ;-) )
> but we might be able to do much better.
>
>
> I know it seems like a trivial thing, but it's not too infrequent that
> I'll hear someone chatting online/posting a follow-up message about how
> they've evaluated PostgreSQl, or another product, but didn't use it
> because we lacked feature foo(), when it's there, and just called feature
> bar().
>
> Anyway, this isn't an itch that I *need* to scratch -- right now,
> all I use in the office is PostgreSQL for backend work :-). But I think in
> the 'how easy are we to evaluate and use' department, it could be a small,
> but helpful win.
>
> --
> Joel Burton <jburton(at)scw(dot)org>
> Director of Information Systems, Support Center of Washington
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026