Selects query inside function must read commited data

[V i s h a l Kashyap @ [Sai Hertz And Control Systems]]

Dear all ,

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

I have a function
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 :
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.
--
Regards,
Vishal Kashyap

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
I Know you believe my words so logon to Jabber.org
and add ***@jabber.org to your roster.
~*~*~*~*~*~*~*~*
I am usually called as Vishal Kashyap
but my Girl friend calls me as Vishal CASH UP.
This is because others know me because of my generosity
and my Girlfriend knows me because of my CASH.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

[V i s h a l Kashyap @ [Sai Hertz And Control Systems]]

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
Would like to receive your kind attention and enormous knowledge on
the following

This tickles me

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
I have a function

So what ?

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
sai_func_a()
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

No one is intrested in your question and thus no answers

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
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
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.

Yes, I need one Why did you ask this question ?
--
Regards,
Vishal Kashyap

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
I Know you believe my words so logon to Jabber.org
and add ***@jabber.org to your roster.
~*~*~*~*~*~*~*~*
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.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Oliver Elphick]

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
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

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.

Within a transaction, you cannot see data committed by any _other_
transaction that had not already committed when your transaction
started.
--
Oliver Elphick ***@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"My little children, let us not love in word, neither
in tongue; but in deed and in truth."
I John 3:18


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[V i s h a l Kashyap @ [Sai Hertz And Control Systems]]

Dear Oliver Elphick ,

Post by Oliver Elphick

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
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 ***@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.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

[Oliver Elphick]

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
Dear Oliver Elphick ,

Post by Oliver Elphick

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
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.

It's in the manual, somewhere; or try it and verify that what I say is
correct.
--
Oliver Elphick ***@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"My little children, let us not love in word, neither
in tongue; but in deed and in truth."
I John 3:18


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Andrew Biagioni]

In the v7.3 docs:

http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XACT-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

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
Dear Oliver Elphick ,

Post by Oliver Elphick

Post by V i s h a l Kashyap @ [Sai Hertz And Control Systems]
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
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.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

[Robert Treat]

All this is well and good, but inside a function you might not see data
that is committed since the query snapshot is not updated within a
function. Search on setQuerySnapshot in the pgsql-bugs list and I think
you'll find more info. So far no one has come up with the evidence
needed to convince the core developers to change this behavior.

Robert Treat

Post by Andrew Biagioni
http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XACT
-READ-COMMITTED
<http://www.postgresql.org/docs/7.3/interactive/transaction-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
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
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.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*