Just realised I didn't cc: the list on this. Was obviously having a good
evening.
Richard Huxton wrote:
Glen Parker wrote:
> I still don't think it will work. Two concurrent transactions could
still screw the data up.
Before: 9 rows.
Tx 1: See 9 rows, issue insert, see 10 rows.
Tx 2: See 9
--
From: "Richard Huxton"
Of course, if you're going to have a separate table then you might as well
store the count in there and actually update it on every
insert/update/delete. Assuming you might find the count of some use
somewhere. Set the
Richard Huxton wrote:
Glen Parker wrote:
Richard Huxton wrote:
#3 won't work unless the other transactions have all committed by the
time you do the check. It is guaranteed to fail at some point.
If it's in an AFTER INSERT/UPDATE trigger then whatever transaction
takes you beyond 10 rows y
Richard Huxton wrote:
Shakil Shaikh wrote:
Hi,
Consider the following scenario:
CREATE FUNCTION test(name)
select into cnt count(id) from items where owner = name;
--suppose someone inserts during this point? then next check will
succeed when it should not.
if (cnt < 10) then
insert into
Glen Parker wrote:
Richard Huxton wrote:
3. Check after an insert on the items table and raise an exception if
there are 11+ items.
I'd be tempted by #3 - assuming most of the time you won't breach this
limit.
#3 won't work unless the other transactions have all committed by the
time you
Shakil Shaikh wrote:
Hi,
Consider the following scenario:
CREATE FUNCTION test(name)
select into cnt count(id) from items where owner = name;
--suppose someone inserts during this point? then next check will
succeed when it should not.
if (cnt < 10) then
insert into items values ('new item
Hi,
Consider the following scenario:
CREATE FUNCTION test(name)
select into cnt count(id) from items where owner = name;
--suppose someone inserts during this point? then next check will succeed
when it should not.
if (cnt < 10) then
insert into items values ('new item', name);
end;
end;
W
