On Tue, 22 Jan 2008, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Tue, 22 Jan 2008, Tom Lane wrote:
> >> Hmm. I wonder why we are bothering with FOR SHARE locks on the
> >> referencing table, when we don't have any intention to change
> >> those rows. Is there some race con
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 22 Jan 2008, Tom Lane wrote:
>> Hmm. I wonder why we are bothering with FOR SHARE locks on the
>> referencing table, when we don't have any intention to change
>> those rows. Is there some race condition that's needed to prevent?
> I think it m
On Tue, 22 Jan 2008, Tom Lane wrote:
> hubert depesz lubaczewski <[EMAIL PROTECTED]> writes:
> > apparently revoking update rights on referencing table blocks deletes on
> > master table:
>
> >> revoke update on b from test;
> > REVOKE
>
> >> delete from a where id = 1;
> > ERROR: permission den
hubert depesz lubaczewski <[EMAIL PROTECTED]> writes:
> apparently revoking update rights on referencing table blocks deletes on
> master table:
>> revoke update on b from test;
> REVOKE
>> delete from a where id = 1;
> ERROR: permission denied for relation b
> CONTEXT: SQL statement "SELECT 1
apparently revoking update rights on referencing table blocks deletes on master
table:
(user test, database test, user test is not superuser)
> create table a (id serial primary key, x text);
NOTICE: CREATE TABLE will create implicit sequence "a_id_seq" for serial
column "a.id"
NOTICE: CREATE
