2017-01-05 11:39 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.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. >
