On Mon, 2012-01-30 at 22:19 +0100, bdmytrak@eranet.pl wrote:
> You handle it somehow for tables (there is no privilage tab in table
> properies when You cannot change privilages). I suppose it is done
> based on ACL for table.
No. On PostgreSQL, it depends if you are superuser or an owner. There
are no ACL granting the rights to alter a table. Within pgAdmin, we only
check if you can create a table in the selected schema.
> This behaviour is not symmetric - works on tables and does not work on
> columns. It leads to misunderstandings, just like in my case. I was
> sure privilages has been granted (no error/warning message has been
> displayed).
Yes, but we can't do anything about this. PostgreSQL also sends a
warning message, and we don't display those because we don't want to
annoy the user with too many messages.
> I also think it is possible to recognize user ability to change column
> level privilages based on ACL (WITH GRANT - signed as star in ACL).
Sure, I don't deny that.
> If the user has privilages WITH GRANT OPTION, eg.
> GRANT UPDATE, INSERT, DELETE, REFERENCES, TRIGGER ON TABLE
> public."tblTest" TO user;
> GRANT SELECT ON TABLE public."tblTest" TO user WITH GRANT OPTION;
> he is allowed to grant select on columns of this table for another
> user. Interesting thing is that, when You (as "user" from my example)
> try to execute:
> GRANT ALL("Column1") ON public."tblTest" TO public;
> then only SELECT privilage on "Column1" is granted - as it is expected
> based on "user" privilages.
>
>
> BTW PostgreSQL generates NOTICE for auto creation of sequence for
> pseudo-type serial not WARNING, so maybe it is good idea to treat
> WARNINGS in the same way as ERRORS?
You'll still get all the warnings messages, and people might not want to
get that.
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com
PostgreSQL Sessions #3: http://www.postgresql-sessions.org