Re: Why Not MySQL?
От | Thomas Lockhart |
---|---|
Тема | Re: Why Not MySQL? |
Дата | |
Msg-id | 390FB42C.88FFFB0D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: Why Not MySQL? (Malcontent null <malcontent@msgto.com>) |
Ответы |
Re: Why Not MySQL?
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-hackers |
> I fully understand that you guys have your own set of priorities. I also > appreciate the work you guys have put into making postgres into a database > I want to use. Having said all that I did wait 4 to 5 days without a reply > of any sort. It would have been perfectly fine for somebody to say "It's not > possible don't waste your time", "Don't ask this question here", "we are > really entirely too busy to deal with this" or even "go away and don't ever > bother us ever again". Well, none of those things are true, and it is rare that someone would speak for a group this widely distributed to say "we are too busy". In most cases, when the usual suspects are too busy someone else will post an answer to a question, and you are never likely to get a definitive "I'm too busy and everyone else is too". At some point, someone may have time to answer *exactly* the questions you asked. Another strategy to try after the first one failed is to come in with the more detailed problem statement, asking for suggestions on a solution. Particularly if you can phrase it so it is clear that it may solve problems for a larger class of user than the one who managed to grow a M$ Access app to 300 tables and 1400 queries before deciding that Access might be a little light in performance to be suitable. But that's water under the bridge, eh? Anyway, so the larger class of problem is for the Sybase/M$ user who relies on case insensitive queries (which *are* available in Postgres) which are indistinguishable from the SQL92-mandated case-sensitive ones. So we might explore the possibilities for a contrib/ module which does this, though because it touches on replacing existing backend code it may not quite fly since there are some function lookup optimizations which may keep you from overwriting the existing routines. But it would be a neat capability to have; I wonder if it would work right away or if we could tweak the backend to allow this in the future?? Of course the alternative is to just dive in and hack and slash at the backend code. Look in parser/gram.y and utils/adt/like.c for starters... - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: