2017-01-04 19:56 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>:

> [...] It is on critical path, so every check increase computer time for
>> transaction end.
> Hmmm... Everything executed is on the critical path...
> It is a very good thing that GUCs are transactional, and this should not
>>> be changed, it is a useful feature! Much more useful than non
>>> transactional.
>> Personally, I never used - although I using often nesting
> Your position is contradictory:
> First you put forward a variable-with-permissions for a special use case,
> you insist that correctness is key and must be checked with static analysis
> tools that audit codes, that dynamic variables are too ugly for the
> purpose. Fine, even if I disagree with some details, there is some logic in
> that: security, audit, checks... why not.
> Then when one shows that correctness requires that the variable is
> transactional, this is not so important anymore based on the fact that some
> big companies do not do it like that, and suddenly it is enough that it
> probably works sometimes. And when the fact that pg already supports
> transactional variables is pointed out, just what the use case needs...
> then you suggest to remove the property.

The GUC are designed for different purpose - I don't know why somebody did
there transaction support - I understand and I remember the nesting

look to code - the GUC related code has more about 10K lines, probably 5K
lines is important for this purpose.

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
1. it is dynamic - not persistent - cannot be used as package variables
2. there is different placing - custom requires prefix - I prefer using our
schemas, because schemas are used  in pg like packages in Oracle
3. large number of GUC decrease performace of end of transactions,
4. any RDBMS using untransactional variables - it should be default
optimized behave



> What can I say? You've lost me, really.
> --
> Fabien.

Reply via email to