Why Not MySQL?

Actually, I'm changing the link

http://openacs.org/why-not-mysql.html

Moments after forwarding the link to Ben's piece on why
MySQL sucks to this list, he e-mailed me the above note.

Sorry for any inconvenience...

I am adding this to the FAQ.

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

A very, very good article. I love the comment about MySQL being a filesystem
with an SQL interface :-)

However.. I'm faced with a huge dilemma.

We use PostgreSQL for a fairly large application I wrote, the database is
still pretty small, it carries info on about 25-30,000 people and about
5,000 jobs. Recently we've had huge trouble with PostgreSQL -- it seems that
every month I stump someone with the obscure things that happen to our data
:-)

From corrupted indexes to corrupted system tables, it's almost always
unrecoverable. Luckily I always have a backup to restore from and the world
goes on... We've only recently started to notice that the backend is slowing
down. It seems that with every additional applicant added it get
exponentially slower... So, sadly I have to go find another backend for this
application -- a commercial one too so we can get "commercial support"
(yuck)..

So, could you guys suggest some other backends I might look into? I know
it's an odd place for me to ask but the flat truth is that I think *I* am to
blame for my Postgres troubles and even taking all of the problems into
account I think PG is the best damn free RDBMS out there. It's functionality
is superior to everyone else's, it's developers are no less than amazing and
well -- I trust you guys to give me some honest opinions.. The functionality
I need is basically what PG has.. Transactions are a must as well as some
sort of sequence -- stability over performance but performance is very
important too. It also needs to run native on FreeBSD..

Oracle is out as we use FreeBSD and someone out there decided that they
wouldn't support FreeBSD (in the license as well as in the code!)..

Thanks guys, especially to all who tried to help in private (Don, Tom --
many others)..

-Mitch

----- Original Message -----
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Don Baccus <dhogaza@pacifier.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Tuesday, May 02, 2000 5:55 PM
Subject: Re: [HACKERS] Why Not MySQL?

At 06:28 PM 5/2/00 -0400, Mitch Vincent wrote:

So, could you guys suggest some other backends I might look into? I know
it's an odd place for me to ask but the flat truth is that I think *I* am to
blame for my Postgres troubles and even taking all of the problems into
account I think PG is the best damn free RDBMS out there. It's functionality
is superior to everyone else's, it's developers are no less than amazing and
well -- I trust you guys to give me some honest opinions.. The functionality
I need is basically what PG has.. Transactions are a must as well as some
sort of sequence -- stability over performance but performance is very
important too. It also needs to run native on FreeBSD..

First, have you been having the same problems with PG 7.0? I recall that
you had it up on a test system but nothing more.

It's a pity that you've reached this point, because PG is so much better
than it was 18 months ago (and before, of course, I mention that timeframe
because that's roughly when I first investigated its suitability for
the web toolkit project) and the trajectory is definitely in the right
direction.

It's also a loss to the development effort, as people with bugs in many
ways are more useful than people who have no problems (though of course
having no bugs for users to stumble across is the best situation!)

Still, I understand the need to solve your problems today, not tomorrow.

Interbase is a possible solution. They have a pretty good reputation,
and their "super server" (threaded with connections sharing a buffer
cache) should scale well. My rough estimate is that they're at about
the place PG will be when 7.1 comes out. I don't know if they support
FreeBSD, though. Any reason you can't just put up a box with Linux?

There's an older version of Sybase available at no charge, again
only for Linux, though.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

exponentially slower... So, sadly I have to go find another backend for this
application -- a commercial one too so we can get "commercial support"
(yuck)..

Actually you might want to give Interbase a try. Version 6 is now in
beta and is going to be open sourced. It's been around a while and seems
pretty solid. There will be a commercial entity to buy support
contracts from and the newsgroups are very helpful. As a bonus there is
a realatively large installed user base already and very very nice
client side tools available. See http://www.interbase.com/ or
http://www.interbase2000.com/ for further details.

If I can't get my questions answered about case sensitivity issues here
(no help so far) I will most likely to use it myself.

I need is basically what PG has.. Transactions are a must as well as some
sort of sequence -- stability over performance but performance is very
important too. It also needs to run native on FreeBSD..

IB supports transactions and sequences. It's very stable and pretty
fast. There was a problem with shared memory in the early beta and
earlier releases but it's fixed now. I am pretty sure it runs on FreeBSD
but I am not sure if it runs natively or under linux emulation.

On Tue, 2 May 2000, Tim Uckun wrote:

If I can't get my questions answered about case sensitivity issues here
(no help so far) I will most likely to use it myself.

What questions? *raised eyebrow*

As Don asks, what happened with the v7.0 trials you were doing? Corrupted
indices, I've seen occasionally in older versions, but I can't recall ever
seeing corrupt system tables ...

I don't have a GUI browser right, so searching the archives is kinda tough
for me :( Can you refresh my memory for me? There has to be something
logical to this, as to what the cause for the corruption is :(

From Don's comment, I take it you are using FreeBSD? Version? Stability
of the machine? Never crashes?

Version of PostgreSQL? Compile/configure options? Do you have any core
files in your data/base/* hierarchy that would be the result of a backend
crashing?

I know you are looking at alternatives, but I'm terrible at letting go of
problems :(

On Tue, 2 May 2000, Mitch Vincent wrote:

A very, very good article. I love the comment about MySQL being a filesystem
with an SQL interface :-)

However.. I'm faced with a huge dilemma.

We use PostgreSQL for a fairly large application I wrote, the database is
still pretty small, it carries info on about 25-30,000 people and about
5,000 jobs. Recently we've had huge trouble with PostgreSQL -- it seems that
every month I stump someone with the obscure things that happen to our data
:-)

From corrupted indexes to corrupted system tables, it's almost always

unrecoverable. Luckily I always have a backup to restore from and the world
goes on... We've only recently started to notice that the backend is slowing
down. It seems that with every additional applicant added it get
exponentially slower... So, sadly I have to go find another backend for this
application -- a commercial one too so we can get "commercial support"
(yuck)..

So, could you guys suggest some other backends I might look into? I know
it's an odd place for me to ask but the flat truth is that I think *I* am to
blame for my Postgres troubles and even taking all of the problems into
account I think PG is the best damn free RDBMS out there. It's functionality
is superior to everyone else's, it's developers are no less than amazing and
well -- I trust you guys to give me some honest opinions.. The functionality
I need is basically what PG has.. Transactions are a must as well as some
sort of sequence -- stability over performance but performance is very
important too. It also needs to run native on FreeBSD..

Oracle is out as we use FreeBSD and someone out there decided that they
wouldn't support FreeBSD (in the license as well as in the code!)..

Thanks guys, especially to all who tried to help in private (Don, Tom --
many others)..

-Mitch

----- Original Message -----
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Don Baccus <dhogaza@pacifier.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Tuesday, May 02, 2000 5:55 PM
Subject: Re: [HACKERS] Why Not MySQL?

Actually, I'm changing the link

http://openacs.org/why-not-mysql.html

Moments after forwarding the link to Ben's piece on why
MySQL sucks to this list, he e-mailed me the above note.

Sorry for any inconvenience...

I am adding this to the FAQ.

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

If I can't get my questions answered about case sensitivity issues here
(no help so far) I will most likely to use it myself.

My recollection is that it involved needing non-standard
case-insensitive LIKE comparisons to get transparent behavior with an
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?

- Thomas

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.

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Mitch Vincent wrote:

A very, very good article. I love the comment about MySQL being a filesystem
with an SQL interface :-)

However.. I'm faced with a huge dilemma.

We use PostgreSQL for a fairly large application I wrote, the database is
still pretty small, it carries info on about 25-30,000 people and about
5,000 jobs. Recently we've had huge trouble with PostgreSQL -- it seems that
every month I stump someone with the obscure things that happen to our data
:-)

What version are you using ?

From corrupted indexes to corrupted system tables, it's almost always

unrecoverable. Luckily I always have a backup to restore from and the world
goes on... We've only recently started to notice that the backend is slowing
down. It seems that with every additional applicant added it get
exponentially slower... So, sadly I have to go find another backend for this
application -- a commercial one too so we can get "commercial support"
(yuck)..

Could you be a little more specific on your performance issues ?

The usual way to deal wih them is tuning your db structure and/or
queries or
setting backend options to use more memory for stuff or other such
things.

If there is something wrong with the structure or queries, then a
database
switch will help you very little, unless your front-end tool has some
special
support for _some_ databases and not for others.

So, could you guys suggest some other backends I might look into?

The usual - Oracle, Interbase, Informix, DB2, Sybase, Solid

The website is usually obtained by putting www inf front and com at the
end ;)

And let us know of your results.

I know
it's an odd place for me to ask but the flat truth is that I think *I* am to
blame for my Postgres troubles and even taking all of the problems into
account I think PG is the best damn free RDBMS out there. It's functionality
is superior to everyone else's, it's developers are no less than amazing and
well -- I trust you guys to give me some honest opinions.. The functionality
I need is basically what PG has.. Transactions are a must as well as some
sort of sequence -- stability over performance but performance is very
important too. It also needs to run native on FreeBSD..

Oracle is out as we use FreeBSD and someone out there decided that they
wouldn't support FreeBSD (in the license as well as in the code!)..

Is FreeBSD a religious issue there or can it be negotiated ?

-------------
Hannu

The Hermit Hacker <scrappy@hub.org> wrote:

On Tue, 2 May 2000, Tim Uckun wrote:

If I can't get my questions answered about case sensitivity issues here
(no help so far) I will most likely to use it myself.

What questions? *raised eyebrow*

The question dealt with trying to acieve case insensitive collation in postgres. Specifically about possibly rewriting the text_cmp or the varchareq functions. I am wondering what kind of mayhem that might cause. I was told by someone who tried it that it's possible to overload the ~~ (like) operator but that dropping the = operator cripples the database so that it's not possible to overload the = operator.

As to why I might want to do this I'll answer that one in response to another question :)
----------
Message To Spammers -- Game Over! Get spam-free email at http://www.MsgTo.com

At , Malcontent null wrote:

The question dealt with trying to acieve case insensitive collation in

postgres. Specifically about possibly rewriting the text_cmp or the
varchareq functions. I am wondering what kind of mayhem that might cause. I
was told by someone who tried it that it's possible to overload the ~~
(like) operator but that dropping the = operator cripples the database so
that it's not possible to overload the = operator.

As to why I might want to do this I'll answer that one in response to

another question :)

Actually, I'd suggest you state the problem you're trying to solve first,
rather
than present the reasons you think PG can't handle the problem without
showing your
hand. Saying, "how can I implement the following solution to an unstated
problem"
rather than simply stating the problem seems ... well, impolite at first
glance.

I'm assuming that you actually are seeking a solution, rather than starting
some sort of crusade in favor of a pet peeve?

Don't misunderstand ... you may be right, there may be no way to solve your
problem efficiently in PG. But until you tell us what you're trying to do,
we have no way to decide whether or not you've actually exhausted the
possibilities.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Thomas Lockhart <lockhart@alumni.caltech.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

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

Don Baccus <dhogaza@pacifier.com> wrote:

Actually, I'd suggest you state the problem you're trying to solve first,
rather
than present the reasons you think PG can't handle the problem without
showing your
hand. Saying, "how can I implement the following solution to an unstated
problem"
rather than simply stating the problem seems ... well, impolite at first
glance.

I admit that I may not be the clearest thinking individual on this planet but I thought I stated my problem in the original post to the best of my ability. I certainly wasn't trying to be rude. Here is a snippet from my original post.

"In a nutshell I want to use postgres as a back end to an access
database. This means that all collation done by postgres musht be case
insensitive including like clauses."

I left the all the spelling mistakes in place :)

----------
Message To Spammers -- Game Over! Get spam-free email at http://www.MsgTo.com

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 well sometimes apps take a life of their own. Database apps in general tend to be too critical to business to just scrap and rewrite 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 people who 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 purpose however 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

"In a nutshell I want to use postgres as a back end to an access
database. This means that all collation done by postgres musht be case
insensitive including like clauses."

I left the all the spelling mistakes in place :)

Could a national char implementation that is case insensitive be a solution
here ?
Meaning: is it as simple as setting LC_COLLATE to another value and
configuring
--enable-locale ?
How far is Thomas with the nchar nvarchar types ?
I think national char and national char varying are the correct datatypes
for
such behavior. Although I think the = operator is still case sensitive for
that datatype.
Replacing = or like for the char and varchar or text datatypes is probably
not possible,
because it is used internally, but for nchar ... it should be.

Andreas

On Tue, 2 May 2000, The Hermit Hacker wrote:

As Don asks, what happened with the v7.0 trials you were doing? Corrupted
indices, I've seen occasionally in older versions, but I can't recall ever
seeing corrupt system tables ...

I don't have a GUI browser right, so searching the archives is kinda tough
for me :( Can you refresh my memory for me? There has to be something
logical to this, as to what the cause for the corruption is :(

From Don's comment, I take it you are using FreeBSD? Version? Stability

of the machine? Never crashes?

Version of PostgreSQL? Compile/configure options? Do you have any core
files in your data/base/* hierarchy that would be the result of a backend
crashing?

I know you are looking at alternatives, but I'm terrible at letting go of
problems :(

His description of table corruption and the system running slower and
slower sounds like a disk going bad. I've seen it hundreds of times
on news machines. Constant retries while trying to write to the disk
will give slowdowns. Having data on a spot of the disk that's unreliable
will certainly cause data integrity problems.

Mitch, have you thoroughly checked the hardware?

Vince.

On Tue, 2 May 2000, Mitch Vincent wrote:

A very, very good article. I love the comment about MySQL being a filesystem
with an SQL interface :-)

However.. I'm faced with a huge dilemma.

We use PostgreSQL for a fairly large application I wrote, the database is
still pretty small, it carries info on about 25-30,000 people and about
5,000 jobs. Recently we've had huge trouble with PostgreSQL -- it seems that
every month I stump someone with the obscure things that happen to our data
:-)

From corrupted indexes to corrupted system tables, it's almost always

unrecoverable. Luckily I always have a backup to restore from and the world
goes on... We've only recently started to notice that the backend is slowing
down. It seems that with every additional applicant added it get
exponentially slower... So, sadly I have to go find another backend for this
application -- a commercial one too so we can get "commercial support"
(yuck)..

So, could you guys suggest some other backends I might look into? I know
it's an odd place for me to ask but the flat truth is that I think *I* am to
blame for my Postgres troubles and even taking all of the problems into
account I think PG is the best damn free RDBMS out there. It's functionality
is superior to everyone else's, it's developers are no less than amazing and
well -- I trust you guys to give me some honest opinions.. The functionality
I need is basically what PG has.. Transactions are a must as well as some
sort of sequence -- stability over performance but performance is very
important too. It also needs to run native on FreeBSD..

Oracle is out as we use FreeBSD and someone out there decided that they
wouldn't support FreeBSD (in the license as well as in the code!)..

Thanks guys, especially to all who tried to help in private (Don, Tom --
many others)..

-Mitch

----- Original Message -----
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Don Baccus <dhogaza@pacifier.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Tuesday, May 02, 2000 5:55 PM
Subject: Re: [HACKERS] Why Not MySQL?

Actually, I'm changing the link

http://openacs.org/why-not-mysql.html

Moments after forwarding the link to Ben's piece on why
MySQL sucks to this list, he e-mailed me the above note.

Sorry for any inconvenience...

I am adding this to the FAQ.

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Malcontent null wrote:

Anyway, so the larger class of problem is for the Sybase/M$ user who
relies on case insensitive queries (which *are* available in Postgres)

Maybe the right place to introduce case-insensitiveness would be in ODBC
driver then ?

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 people who 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
purpose however it needs a few things.
1) Longer object names (I guess this is possible via a DEFINE)

How long should they be ?

2) Case insensitive queries.

Probably only the Access subset ("like", "order by", maybe even "=" ?)

3) Outer joins (coming soon!).
4) Maybe ADO drivers for the VB users of the world.

AFAIK MS moves fast and ADO will be soon (or is already) officially obsolete.

The technology du jour is XML.

I don't know how important access integration is to the postgres
community as a whole though.

Probably not a top priority. Oracle is much more often seen as the target.

---------------------
Hannu

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.

Not to turn you away from PostgreSQL, but you might want to look at MSDE
(Microsoft Data Engine) as an easier step. It has the same query processor
as SQL Server, but scales much better (and includes transaction logs etc).
See for example
http://msdn.microsoft.com/library/backgrnd/html/msdeforvs.htm.
The license for MSDE is also included in Office 2000 Pro/Premium, so chances
are you may already have the required licenses.
Still leaves you in the Microsoft box, though.

//Magnus

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
people who 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 purpose
however 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.

Should be no major need for a separate ADO driver for Pg. You can use ADO
going through the ODBC driver, which already exists.

//Magnus