OK thanks for the advice. What I'm trying to overcome is where we've got a long report running and the process that is taking data from the main database cannot complete because of the drop table. I believe a DELETE (and possibly TRUNCATE?) doesn't need an exclusive lock on the table and therefore can continue.
I've introduced a --delete-not-drop option which simply does a DELETE FROM % rather than 'DROP and then CREATE'. I hope this sounds sensible and I haven't missed something - I'm still learning! Rob 2008/11/25 Gregory Stark <[EMAIL PROTECTED]> > "Rob Kirkbride" <[EMAIL PROTECTED]> writes: > > > Once I'm happy with it (I'm a bit rusty at C!), do I post the patch here? > > I would say you should post *before* you have a patch you're happy with. As > soon as you have a specific plan of what you want to do it's best to post > an > outline of it. That way you at least have a chance of avoiding wasting work > in > the wrong direction. > > Sometimes things don't really work out that way -- sometimes the plan > sounds > good and it only becomes apparent there's a better way later -- but you're > best off getting the best chance you can. > > Incidentally, I don't know exactly what the use case you're trying to cover > here is but you should consider looking at TRUNCATE instead of DELETE if > you're really deleting all the records in the table and can accept locking > the > table. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's Slony Replication support! >
