Scott Shattuck <[EMAIL PROTECTED]> writes:
> ...why don't they allow the selects to read through adding a
> constraint?
Hmm. We could probably allow that --- at least for some forms of
ALTER TABLE, a ShareRowExclusive lock ought to be good enough.
(That would allow SELECT and SELECT FOR UPDATE t
On Wed, 2002-09-04 at 22:49, Tom Lane wrote:
> Scott Shattuck <[EMAIL PROTECTED]> writes:
> > ... I don't understand why an exclusive table-level lock is being
> > taken out to add a trigger.
>
> Well, that's a schema change; it makes sense to me to forbid access
> while we're changing a table's
On 4 Sep 2002, Scott Shattuck wrote:
> On Wed, 2002-09-04 at 15:51, Stephan Szabo wrote:
> >
> > On 4 Sep 2002, Scott Shattuck wrote:
> >
> > > Under what conditions would the following statement cause the USERS
> > > table to lock out selects?
> > >
> > >
> > > alter table my_coupons
> > > ad
Scott Shattuck <[EMAIL PROTECTED]> writes:
> ... I don't understand why an exclusive table-level lock is being
> taken out to add a trigger.
Well, that's a schema change; it makes sense to me to forbid access
while we're changing a table's schema.
I think this discussion may just be a miscommuni
On Wed, 2002-09-04 at 15:51, Stephan Szabo wrote:
>
> On 4 Sep 2002, Scott Shattuck wrote:
>
> > Under what conditions would the following statement cause the USERS
> > table to lock out selects?
> >
> >
> > alter table my_coupons
> > add constraint FK_mc_user_id
> > FOREIGN KEY (mc_frn_user
On 4 Sep 2002, Scott Shattuck wrote:
> Under what conditions would the following statement cause the USERS
> table to lock out selects?
>
>
> alter table my_coupons
> add constraint FK_mc_user_id
> FOREIGN KEY (mc_frn_user_id)
> REFERENCES users(user_ID);
If I'm reading code correctly, an
Hi,
Under what conditions would the following statement cause the USERS
table to lock out selects?
alter table my_coupons
add constraint FK_mc_user_id
FOREIGN KEY (mc_frn_user_id)
REFERENCES users(user_ID);
ss
Scott Shattuck
Technical Pursuit Inc.
---(end of
