Tom Lane schreef:
> jef peeraer <jef.peeraer@telenet.be> writes:
>> Tom Lane schreef:
>>> That's a foreign-key check, which is supposed to be done as the owner of
>>> the table. You did not show us who owns table clienten, but I think
>>> that role must be missing the intended(?) membership in deterp_group.
>
>> registratie=# \z deterp.clienten;
>> Access privileges for database "registratie"
>> Schema | Name | Type | Access privileges
>> --------+----------+-------+------------------------------------------
>> deterp | clienten | table | {jpe=arwdxt/jpe,deterp_group=arwdxt/jpe}
>
> Hmm. This doesn't actually say so, but I think that jpe must be the
> owner of clienten, and he's also the owner of the schema. Which makes
> the failure really darn odd.
>
> I tried to reproduce the situation on 8.1.9 and couldn't see any
> problem. I do not see anything in the 8.1 CVS history that looks
> related, but it's slightly possible this is a bug that's fixed between
> 8.1.3 and 8.1.9 (and even if that is not the case, you really really
> ought to update anyway).
ok, i upgraded anywway to the latest stable one, also because i needed
the 'drop table if exists' feature.
it was indeed a foreign referenced table that was not owned by jpe. i
must have overlooked it.
thanks for you're time anyway.
jef peeraer
>
> Would you see if the problem recurs if you do a pg_dump -s and load the
> schema into a fresh database? If it doesn't, perhaps there is some
> weird corruption in the ACL entries. If it is reproducible, please post
> the complete schema (or enough of it to reproduce the problem) to
> pgsql-bugs.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>