Re: Two features left - add

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(at)postgresql(dot)org)