Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: SE-PostgreSQL Specifications
Date
Msg-id 20090804031855.GJ23840@tamriel.snowman.net
Whole thread Raw
In response to Re: SE-PostgreSQL Specifications  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: SE-PostgreSQL Specifications  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Re: SE-PostgreSQL Specifications  (David Fetter <david@fetter.org>)
List pgsql-hackers
KaiGai,

* KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
> I began to describe the list of abstraction layer functions (but not completed yet):
>   http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction

I'm not really a huge fan of 'security_' as a prefix for these
functions, but I don't have a better suggestion right now.

The initial abstraction patch shouldn't include the security context
pieces.  I realize that will be needed eventually, but the patch to do
the abstraction and to formally move permissions checking to aclchk.c
needs to stand alone.  I'm also not sure that the API of having the
security context be returned as a Datum makes sense..

Doesn't security_table_permissions() need to know if the query is an
UPDATE or an INSERT?
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: pg_proc.probin should become text?
Next
From: Robert Haas
Date:
Subject: Re: SE-PostgreSQL Specifications