Two features left - Mailing list pgsql-general

MS-SQLI have been using PostgreSQL on one of my projects since the beginning
of the year now.  Before that I used Oracle and .  I am very impressed with
the stability, speed, and usefulness PostgreSQL and think the 7.2.3 release
will be grand.  PostgreSQL wins out over the other open source DBs because it
has those basic features needed for a fully formed data model such as foreign
keys, transactions, and the speed to go with them.  PostgreSQL is on the
verge of winning big against closed source as well.  What is standing in the
way, in my opinion, is two features.  I came to this conclusion after
thinking about all the previous projects I have been involved with and how
PostgreSQL could be used in place of the closed source DB in 90% of them with
the following:

Read locks for Foreign Key references
SQL exception should not void a transaction

Based on reading the email list for the past 8 months, others have voiced
these issues as well.  Some would say that replication and/or failover should
also be on the list.  However, I think interaction within the DB is more
important as there is no work around in many cases.

As many of you know, PostgreSQL takes a write lock on a referenced foreign key
record when you update or lock a record in a transaction.  This results in a
great many delays and deadlocks on a high volume system that uses foreign
keys.  Some would say to just not use foreign keys and make the application
keep things straight.  Foreign keys are one of the things that attracts
people to PostgreSQL, why would you want to tell them not to use them.  Also,
there are a lot of existing applications out there that would port themselves
to use PostgreSQL but not if they have to re-write the way their software
works.  It is also not a safe assumption that the application will be the
only thing accessing the DB.  DBAs make mistakes too, and foreign keys often
catch them.  I have made inquires into how much it would cost to make this
feature a reality to see if I could get a customer to finance it but have not
received a response.

The other feature is to allow transactions to continue without being forced to
rollback when a SQL exception occurs.  In many applications, a SQL exception
is handled and an appropriate alternative generated so the transaction goes
on.  PostgreSQL does not support this and errors on every call made in the
same transaction before calling rollback.  Some people are willing and able
to adjust there application code to handle this.  Many people have long
running transactions where this is not easily accomplished or are using a
pre-existing application that they can't change.

The point of this email is that I would like to be able to profess the joys
and greatness of PostgreSQL to all my customers and whom ever else will
listen.  With these features I could do that easily.