Re: Re: postgres TODO - Mailing list pgsql-hackers

From Philip Warner
Subject Re: Re: postgres TODO
Date
Msg-id 3.0.5.32.20000710233217.02511b10@mail.rhyme.com.au
Whole thread Raw
In response to Re: Re: postgres TODO  (Alessio Bragadini <alessio@albourne.com>)
List pgsql-hackers
At 09:14 10/07/00 -0400, eisentrp@csis.gvsu.edu wrote:
>On Mon, 10 Jul 2000, Alessio Bragadini wrote:
>
>> > I don't get the point of this. Don't you know what you inserted? For
>> > sequences there's curval()
>> 
>> Mmmhhh... it means that we can assume no update to the sequence value
>> between the insert and the curval selection?
>
>Sequences are transaction safe.
>

Really? I thought I read somewhere that they did not rollback so that
locking could be avoided, hence they would not be a major source of
contention. If that is true, it does seem to imply that they can be updated
by other processes (Otherwise they would present a locking problem). Or do
you mean that they maintain a 'curval' that was the last value use in the
current TX?

Either way it's still not a help, consider:

create table t1(f1 int4, f2 text);

create trigger t1_ir_tg1 after insert on t1
(   insert into t1_audit(t1.id, nextval('id'), "Row created");
) for each row;

insert into t1(nextval('id'), "my main row");

Not necessarily a real case, and fixed by using two sequences. But with a
more complex set of triggers or rules, there is a real chance of stepping
on curval().

How hard would it be to implement:
   insert into t1(nextval('id'), "my main row") returning f1, f2;

or similar?

[in the above case, the insert statement should be identical to:
   insert into t1(nextval('id'), "my main row") returning f1, f2;   select f1, f2 from t1 where oid=<new row oid>
]

----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: postmaster errors with index on temp table?
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Re: [GENERAL] PostgreSQL vs. MySQL