Re: proposal: session server side variables

>> 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.