Thomas Lockhart <lockhart@alumni.caltech.edu> wrote:
>
>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?
Actually I did post twice I had hoped that I was being more clear the second time. As for growing the access database
wellsometimes apps take a life of their own. Database apps in general tend to be too critical to business to just scrap
andrewrite so they just keep growing.
>Anyway, so the larger class of problem is for the Sybase/M$ user who
>relies on case insensitive queries (which *are* available in Postgres)
If I may.
MS Access for all of it's damnable faults is the single most popular database in the world. There are a whole slew of
peoplewho do nothing except access programming and make very good money at it. Postgres is a great candidate as a
possible back end database engine for access. This is a big possible application for postgres. To be usable for this
purposehowever it needs a few things.
1) Longer object names (I guess this is possible via a DEFINE)
2) Case insensitive queries.
3) Outer joins (coming soon!).
4) Maybe ADO drivers for the VB users of the world.
I don't know how important access integration is to the postgres community as a whole though.
>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...
Thanks for the tip I'll start looking at this right away.
----------
Message To Spammers -- Game Over! Get spam-free email at http://www.MsgTo.com