> * ACL_INSERT
> The db_table:{insert} and db_column:{insert} for all the target
> columns are checked. The table-level permission does not override
> column-level permission, so the client need to have privileges
> for both of objects. It is same as other permissions.
>
> * ACL_SELECT
> The db_table:{select} and db_column:{select} for all the target
> columns are checked.
> But it applies db_table:{lock} on LockTableCommand().
>
> * ACL_UPDATE
> The db_table:{update} and db_column:{update} for all the target
> columns are checked.
>
> * ACL_DELETE
> The db_table:{delete} is also checked. No column-level checks here.
I'm more or less with you up to this point.
> * ACL_TRUNCATE
> The db_table:{delete} is also checked.
> SE-PostgreSQL does not discriminate between TRUNCATE and DELETE.
But this seems wrong.
> * ACL_REFERENCES
> * ACL_TRIGGER
> SE-PostgreSQL does not care about these privileges.
> But, it checks db_procedure:{execute} on trigger invocation time,
> and it also checks db_table:{select} on checks of FK constraint
> within its secondary SQL execution.
And so do these. Why should there be any asymmetry with regular
PostgreSQL here?
> * ACL_EXECUTE
> The db_procedure:{execute} is also checked.
> This check is embedded within pg_proc_ackcheck().
Good...
> * ACL_USAGE
> * ACL_CREATE
> * ACL_CREATE_TEMP
> SE-PostgreSQL does not care about there privileges.
Again, there doesn't seem to be any reason for this asymmetry. I
think you should change it.
...Robert
