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@scw.org>
> Director of Information Systems, Support Center of Washington
>
>

--
  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