From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Trewern, Ben" <Ben(dot)Trewern(at)mowlem(dot)com> |
Cc: | "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Updating pg_attribute - Permission denied |
Date: | 2000-10-22 03:08:05 |
Message-ID: | 2446.972184085@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Trewern, Ben" <Ben(dot)Trewern(at)mowlem(dot)com> writes:
> I was trying to update attnotnull = 't' in the pg_attribute to add Not Null
> constraint to a table. It gave me a Permission denied.
> Is this standard? Am I not allowed to change system catalogues (I am using
> the postgres superuser!)
I don't believe it --- are you *sure* you were superuser? Or perhaps
you'd turned off pg_shadow's usecatupd for yourself?
I get this behavior:
play=> update pg_attribute set attnotnull = 't' where attrelid = 334893 and
play-> attname = 'f1';
ERROR: pg_attribute: Permission denied.
play=> \c - postgres
You are now connected as new user postgres.
play=# update pg_attribute set attnotnull = 't' where attrelid = 334893 and
play-# attname = 'f1';
UPDATE 1
play=#
> Or can you only change attnotnull to false i.e. remove a not null
> constraint? I suppose this would make some kind of sense, as there
> could already be Nulls in the field.
It's up to you to worry about that sort of consistency issue if you
reach in and hack pg_attribute directly. Certainly the permission
check is not concerned with it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-10-22 13:19:19 | Re: How does TOAST compare to other databases' mechanisms? |
Previous Message | Tom Lane | 2000-10-22 02:58:09 | Re: Out of memory errors with mod_perl |