Re: Two features left - add - Mailing list pgsql-general

Add
- cursor out of a transaction
- distributed database (two phase commit)
- replication

regards
Haris Peco
On Wednesday 27 November 2002 05:13 pm, Jon Swinth wrote:
> 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)