In the v7.3 docs:
http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XACT-READ-COMMITTEDRead Committed is the default isolation level in
PostgreSQL. When a transaction runs on this isolation level, a
SELECT query sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. (However, the
SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed.) In effect, a
SELECT query sees a snapshot of the database as of the instant that that query begins to run. Notice that two successive
SELECTs can see different data, even though they are within a single transaction, if other transactions commit changes during execution of the first
SELECT.
Andrew
V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote:
Dear Oliver Elphick ,
If I am not wrong PostgreSQL select statements works on committed data
thus the new
inserted data at #3 must not be available to sai_func_b() till #5
No. All operations by a single transaction are visible inside the
transaction. Therefore an encapsulated function can see anything already
done in the whole transaction. A function must be entirely inside a
transaction and cannot start a transaction, so there can never be any
problem about this.
Loads of thanks for the kind reply .
Would be greatefull if you kindly post some links/refrences to support your answer for the said.
Thanks one again .
--
Regards,
Vishal Kashyap
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
I Know you believe my words so logon to Jabber.org
and add vishalkashyap@jabber.org to your roster. OR
Seek Me at 264360076
~*~*~*~*~*~*~*~*
I am usually called as Vishal Kashyap
but my Girlfriend calls me as Vishal CASH UP.
This is because others identify me because of my generosity
but my Girlfriend identify me because of my CASH.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*