Re: proposal: session server side variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: proposal: session server side variables
Date: 2017-01-04 19:24:19
Message-ID: CAFj8pRBW3-7WjAXC-YOA92xZBJw75b9UdRfy+JZnbYuw_W8fxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-01-04 19:56 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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
support.

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
simply
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,
subtransactions
4. any RDBMS using untransactional variables - it should be default
optimized behave

Regards

Pavel

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-01-04 19:30:47 Re: pg_recvlogical --endpos
Previous Message Tom Lane 2017-01-04 19:20:52 Re: pgsql: Update copyright for 2017