Robert Treat wrote:
On Thu, 2004-08-26 at 09:08, Gaetano Mendola wrote:
Robert Treat wrote:
On Thu, 2004-08-26 at 04:23, Gaetano Mendola wrote:
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
I believe it sees the one that was valid in the snapshot as of the
beginning of the function.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Treat wrote:
| On Thu, 2004-08-26 at 09:08, Gaetano Mendola wrote:
|
|>Robert Treat wrote:
|>
|>
|>>On Thu, 2004-08-26 at 04:23, Gaetano Mendola wrote:
|>>
|>>
|>>>Tom Lane wrote:
|>>>
|>>>
|Stephan Szabo <[EMAIL PROTECTED]> writes:
|
|>>
On Thu, 2004-08-26 at 09:08, Gaetano Mendola wrote:
> Robert Treat wrote:
>
> > On Thu, 2004-08-26 at 04:23, Gaetano Mendola wrote:
> >
> >>Tom Lane wrote:
> >>
> >> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> >
> >> >>I believe it sees the one that was valid in the snapshot as of the
> >> >
Robert Treat wrote:
On Thu, 2004-08-26 at 04:23, Gaetano Mendola wrote:
Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>
>>I believe it sees the one that was valid in the snapshot as of the
>>beginning of the function.
>
>
> Actually, the problem is that it can see *both* that row and
On Thu, 2004-08-26 at 04:23, Gaetano Mendola wrote:
> Tom Lane wrote:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> >
> >>I believe it sees the one that was valid in the snapshot as of the
> >>beginning of the function.
> >
> >
> > Actually, the problem is that it can see *both* that ro
Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>
>>I believe it sees the one that was valid in the snapshot as of the
>>beginning of the function.
>
>
> Actually, the problem is that it can see *both* that row and the updated
> row; it's a crapshoot which one will be returned by the SE
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I believe it sees the one that was valid in the snapshot as of the
> beginning of the function.
Actually, the problem is that it can see *both* that row and the updated
row; it's a crapshoot which one will be returned by the SELECT INTO.
The reason this
On Thu, 26 Aug 2004, Gaetano Mendola wrote:
> Stephan Szabo wrote:
>
> > On Wed, 25 Aug 2004, PostgreSQL Bugs List wrote:
> >
> > Actually, it shows that functions have odd behavior when locking is
> > involved (your statement would potentially be true if you could replicate
> > this without the f
Stephan Szabo wrote:
On Wed, 25 Aug 2004, PostgreSQL Bugs List wrote:
CREATE OR REPLACE FUNCTION test_tr() RETURNS numeric AS'
DECLARE
a numeric;
b numeric;
BEGIN
select next_number into b from test_trans where id=1;
update test_trans set next_number=next_number+1 where id=1;
select next_number i
On Wed, 25 Aug 2004, PostgreSQL Bugs List wrote:
> CREATE OR REPLACE FUNCTION test_tr() RETURNS numeric AS'
> DECLARE
> a numeric;
> b numeric;
> BEGIN
> select next_number into b from test_trans where id=1;
> update test_trans set next_number=next_number+1 where id=1;
> select next_number into
The following bug has been logged online:
Bug reference: 1231
Logged by: Piotr Figiel
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.3
Operating system: Linux Suse
Description:Probelm with transactions in stored code.
Details:
Hello
I have a problem w
11 matches
Mail list logo
