Re: ODBC 3.0 functions (UCASE, LCASE, etc.)
От | Bruce Momjian |
---|---|
Тема | Re: ODBC 3.0 functions (UCASE, LCASE, etc.) |
Дата | |
Msg-id | 200105031913.f43JDpq11999@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: ODBC 3.0 functions (UCASE, LCASE, etc.) (Joel Burton <jburton@scw.org>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: