Re: proposal: session server side variables

2017-01-05 11:39 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Pavel,
>
> There are more reasons, why I would not to use GUC
>>
>
> 0. it is not designed be secure - there is different security model -
>> readonly, superuser, others
>>
>
> Sure, GUCs as is are not enough, but the model can be extended instead of
> re-inventing the wheel with a new kind of variable.
>
> 1. it is dynamic - not persistent - cannot be used as package variables
>> simply
>>
>
> Half-persistence (in definition, not in value) is not a key feature needed
> by the use-case.
>
> 2. there is different placing - custom requires prefix - I prefer using our
>> schemas, because schemas are used in pg like packages in Oracle
>>
>
> Idem.
>
> 3. large number of GUC decrease performace of end of transactions,
>> subtransactions
>>
>
> That is life. The presented use-case really needs only one variable.
>
> 4. any RDBMS using untransactional variables - it should be default
>> optimized behave
>>
>
> Hmmm. Untransactional variables do **NOT** fit the use case, it just works
> "sometimes", which is not acceptabe.
>
> I've spent too much time on reviewing this proposal. My conclusion is:
>
> - a clear use case linked to security setups has been presented
> which requires some kind of secure (i.e. with access control) session
> variables, currently not available in pg which has user-defined GUC
> which are dynamic, untyped (TEXT), public, transactional.
>
> - you have proposed a NEW kind of session variables which is:
>
> (1) statically typed, declared permanently in the catalog, in the
> schema/table namespace
>
> (2) values are session alive
>
> (3) untransactional, as you insist on that (your 4. above)
>
> (4) with permissions
>
>
> My feedback is that:
>
> - The proposed feature does not fit the presented use case it is intended
> for. There is no use case for untransactional secure session variables.
> The proposal should be amended so that the variables display by default
> some transactional properties because it is required for correctly
> implementing the use case.
>
> - Personnaly, I'm not convinced that a NEW type of session variable is
> a good thing as pg already has one, and two is one too many. I would
> find it more useful to enhance existing dynamic session variables with,
> by order of importance:
>
> (1) private/public visibility (as Oracle does with package vars).
> this point is enough to implement the presented use case.
>
> (2) typing (casting is a pain)
>
> (3) improved syntax (set_config & current_setting is a pain)
>
> Eventually, unrelated to the use case, but in line with your motivations
> as I understand them:
>
> (4) add an option to make a GUC non transactional, iff there is
> a clear use case for that (maybe debug?).
>
> (5) have some "permanent" GUC type declarations (maybe editing the
> config file does that already, by the way?)
>
>
Thank you for your work on this topic.

Unfortunately, there is significant disagreement in this topic between us.
I see a schema based persistent metadata a catalog based security as
fundamental feature. Editing config file is not acceptable in any view.

Best regards

Pavel

> --
> Fabien.
>