quote:

---

>
> Would like to receive your kind attention and enormous knowledge on
> the following

---

quote:

---

>
> I have a function

---

quote:

---

> sai_func_a()
> Which does as follows and in the same order:
> 1. Retrieves the latest record from the table test_sai
> (By latest I mean the record corresponding to max primary key of
> the table)
> 2. Increments date as received from test_sai.current_date
> as my_new_date := test_sai.current_date + 1 ;
> 3. Inserts the new date into the same table test_sai
> 4. Calls another function sai_func_b()
> Now inside sai_func_b()
> 1. Does as #1 of above
> 2. Works on the date in the last record.
> 3. Returns success code to sai_func_a()
> 5. The sai_func_a() finishes the work
>
> Now My question :

---

quote:

---

> Since sai_func_a() which encapsulates the function sai_func_b has not
> completed yet till #4 or #5
> then how does the function sai_func_b reads the new data since it is
> not committed yet.
>
> 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
>
> Server Specs:
> 1. version
> ---------------------------------------------------------------------------------------------------------
> PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2
> 20030222 (Red Hat Linux 3.2.2-5)
> 2.Both functions are plpgsql and are not triggers
>
>
>
> If you need more information kindly ask for the same.

---

quote:

---

> Since sai_func_a() which encapsulates the function sai_func_b has not
> completed yet till #4 or #5
> then how does the function sai_func_b reads the new data since it is
> not committed yet.
>
> 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

---

quote:

---

>
>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.
>
>

---

quote:

---

> Dear Oliver Elphick ,
> Loads of thanks for the kind reply .
> Would be greatefull if you kindly post some links/refrences to support
> your answer for the said.

---

quote:

---

> Dear Oliver Elphick ,
>
> 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.
> ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
~*~*~*~*
>
>

---

quote:

---

> In the v7.3 docs:
>
> http://www.postgresql.org/docs/7.3/...n-iso.html#XACT
> -READ-COMMITTED
> <http://www.postgresql.org/docs/7.3/...on-iso.html#XAC
> T-READ-COMMITTED>
>
> Read 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 <mailto: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.
>
> ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
~*~*~*~*
>
>
>

---