Re: Why Not MySQL?

> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California

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

That would be my recommendation. It is open source, so you can modify
it however you like.

--
Bruce Momjian | http://www.op.net/~candle
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

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> wrote:

>existing M$ Access app. So far, we were too polite to ask why one is
>working so hard to maintain compatibility with a non-standard
>interface, rather than writing the app to be portable. But I'll ask
>now. Tim?

Fair enough question. I agree with you that this is non standard typical MS lock in crap. But I have an application that is written in access and has outgrown the data engine in access (which is pretty pathetic). Unfortunately this application is very large with over 300 tables and over 1400 saved queries (views). The MS solution to this problem is to upgrade to MS-SQL server (vendor lock in) which processes the queries in the exact same case insensitive manner. SQL server does not break my application. I on the other hand want to avoid upsizing to SQL server. I could use sybase which also allows for case insensitive collation (no surprise there) but I really-really want to use an upen source database server.
So. So right now I have a few choices.
1) Buckle into the vendor lock and be stuck with NT and SQL server
2) Buy sybase and spend way more then I want to.
3) Completely rewrite all 1400 queries and write all kinds of new code make sure the SQL emitted by access gets intercepted and translated properly.
4) Make Postgres process queries case insensitively.

Well the third one is out of the question really I don't have that kind of time or money. It would take me a the rest of the year to accomplish that goal and the database would have to be taken out of commision in the meantime.

>
>btw, it seems to be the case that problems such as these, which might
>be interesting during slow times (from a theoretical standpoint at
>least), are decidely less so during the final stages of a release
>cycle.

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".
----------
Message To Spammers -- Game Over! Get spam-free email at http://www.MsgTo.com