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 vishalkashyap@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.
 ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
~*~*~*~*

[ Post a follow-up to this message ]

quote:

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


This tickles me
quote:

>
> I have a function


So what ?
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 :


No one is intrested in your question and thus no answers
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.


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 vishalkashyap@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

[ Post a follow-up to this message ]

On Sun, 2004-01-25 at 08:51, V i s h a l Kashyap @ [Sai Hertz And
Control Systems] wrote:
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


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

[ Post a follow-up to this message ]

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

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

[ Post a follow-up to this message ]

On Sun, 2004-01-25 at 16:31, V i s h a l Kashyap @ [Sai Hertz And
Control Systems] wrote:
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.


It's in the manual, somewhere; or try it and verify that what I say is
correct.
--
Oliver Elphick                                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

[ Post a follow-up to this message ]

In the v7.3 docs:

http://www.postgresql.org/docs/7.3/...MM
ITTED

/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:
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.
> ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
~*~*~*~*
>
>

[ Post a follow-up to this message ]

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

On Sun, 2004-01-25 at 13:09, Andrew Biagioni wrote:
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.
>
>  ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
~*~*~*~*
>
>
>


--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 3: 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

[ Post a follow-up to this message ]