Re: Re: postgres TODO

At 09:14 10/07/00 -0400, eisentrp(at)csis(dot)gvsu(dot)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 |/