Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id alpine.DEB.2.20.1612290937040.4911@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] proposal: session server side variables
List pgsql-hackers
>> CREATE FUNCTION setup_user(TEXT, TEXT)
>>   RETURNS BOOLEAN SECURITY DEFINER AS $$

>> CREATE FUNCTION isUserAuditor()
>>    RETURNS BOOLEAN SECURITY DEFINER AS $$
>
> so what is worse - I did one new entry in pg_class and one entry in
> pg_attributes. You wrote two entries in pg_proc function - more you have to
> ensure consistency of these functions.

You are not comparing the same perimeter, the setup_user() function is 
necessary to both approaches for the described use case where a read-only 
value is needed:

With your approach:
  1. CREATE VARIABLE secure_stuff SESSION SCOPE ...  2. REVOKE/GRANT ... on VARIABLE secure_stuff  3. CREATE FUNCTION
setup_user(...)

With this approach:
  1. CREATE FUNCTION access_secure_stuff(...)  2. REVOKE/GRANT ... on FUNCTION access_secure_stuff  3. CREATE FUNCTION
setup_user(...)

The REVOKE/GRANT are basically the same on VARIABLE and on FUNCTION.

So it is not really that different as far as catalog entry count is 
concerned.

The benefit is that it avoids a special concept and use a more generic 
one, i.e. basic session variables.

The added cost is that a two line function must be written, which does not 
look like a big issue to implement a pretty special use case.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: session server side variables