Subject: Re: Detecting which columns a query will modify in a function called
 by a trigger
To: stan <stanb@panix.com>
Cc: pgsql-general@lists.postgresql.org
References: <20200302185904.GA6528@panix.com>
 <30c3c06e-61fa-3210-666d-1696af320a75@aklaver.com>
 <20200302202829.GA19161@panix.com>
From: Adrian Klaver <adrian.klaver@aklaver.com>
Message-ID: <e2884f34-8d8f-0f08-8fbc-5578bdb6033f@aklaver.com>
Date: Mon, 2 Mar 2020 13:11:19 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200302202829.GA19161@panix.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/2/20 12:28 PM, stan wrote:
> On Mon, Mar 02, 2020 at 11:02:54AM -0800, Adrian Klaver wrote:
>> On 3/2/20 10:59 AM, stan wrote:
>>> I need to implement a fairly fine grained security model. Probably a bit
>>> finer that I can do with the standard ownership functionality.
>>>
>>> My thinking on this is to create a table that contains the users, and a
>>> "permission bit" for each function that they may want to do, vis a vi
>>> altering an existing row,or rows, or inserting new rows.
>>>
>>> Looks relatively straight forward, if fairly time consuming to do. But I
>>> would need to know which column(s) a given query would add..alter from the
>>> function to implement this via a trigger. looks like I see most of what I
>>> need t do this in the docs, but I can't quite figure out if I can get this
>>> down to what column(s) a given trigger will modify. Is this possible?
>>
>> Before you get too far into this I would look at RLS:
>>
>> https://www.postgresql.org/docs/12/ddl-rowsecurity.html
>>
> Thanks for pointing that out.
> 
> Using that functionality was my original plan, but let me describe why I do not think it
> can do what I need. This may be an indication of my weakness in design
> though.

Yeah, I'm going to go with the other commenters and say this design 
needs work. My feeling is that if there is a division of labor it should 
be reflected in the tables. To me it seems easier to build a overall 
look from smaller units, then trying to decompose a larger unit into 
smaller units of work.

> 
> Envision a table with a good many columns. This table represents the "life
> history" of a part on a project. Some of the columns need to be
> created/modified by the engineer. Some need to be created/modified by the
> purchasing agent, some of the columns need to be created by the receiving
> department, some of the columns need to be created/modified by the accounts
> payable department.
> 
> Make sense?
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com