Re: Detecting which columns a query will modify in a function called by a trigger

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(dot)klaver(at)aklaver(dot)com