> >
> > In the latter, you have expanded the scope of the transaction; which,
> > sometimes you might want to do.
>
> Yes, I might. But, I'd like to understand it so I do know when I might
> or might not want to do it.
Understanding is good. You need to read the documentation on transactions:
http://www.postgresql.org/docs/7.4/interactive/tutorial-transactions.html
and Concurrency control:
http://www.postgresql.org/docs/7.4/interactive/mvcc.html
>
> Say I have a BEFORE INSERT trigger that does a table lock. When
> is that lock released? At the end of the trigger? Or after the
> INSERT has completed?
At the end of the transaction.
>
> For example, say I want to set a column on the row I'm inserting based
> on what's already in the table. So I lock the table in the trigger
> and check the current status of the table and set the column based on
> that current status.
>
> I want to make sure that between the time the trigger completes and
> when the insert finally happens that another session can't also do an
> insert and see the same table state.
Again, reading the docs on concurrency control and transactions will answer
these questions.
>
>
>
> --
> Bill Moseley
> moseley@hank.org
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
