Re: SELECT FOR UPDATE

> It seems to me that SELECT ... FOR UPDATE is not the way to go if
> it is possible that the selected record may be held for any length
> of time.

But transactions are supposed to occur very quickly.

> For instance, say you are storing web pages in the database, and you
> want a number of developers to be able to get pages from the database
> look at them, and possibly make changes and update the record.

In this case, I would use webDAV, not a RDBMS, unless I needed
relations between the documents that I couldn't get by simply using a
directory structure.

> So, the lock table would need a time-out field, and might also
> include a queue of people waiting for the record.

Yes, this is what confuses me most about Jan's post.  The lock table
functionally resides between the RDMBS and the application/user, and
in doing so it defeats the purpose of an RDBMS.  What should I use
triggers, rules, and listen/notify for then?   I guess LISTEN/NOTIFY
could be used in conjunction with the lock table.

> This is just how I was thinking of it, and again I think it will
> depend on the application. At some point, you're not making a
> database, you're creating a cvs. Though a hybrid could be good....

Exactly, your not making a database, and as for the hybrid...  This is
why XML is such overhyped shit right now, nobody likes/trusts RDBMS's.