| 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>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: session server side variables |
| Date: | 2016-12-29 09:00:05 |
| Message-ID: | CAFj8pRBnmHqhYSuTHHPcxHjtM9a02gXJ=ai329fh90LXCOWfrg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2016-12-29 9:57 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> Please, could you remove the part of the mail you are not responding to
> and just keep the relevant part?
>
> Whatever the features and syntax, you can always shoot yourself in the
>>> foot.
>>>
>>
>> I disagree
>>
>
> Hmmm... I have succeeded in shotting myself in the foot with possibly
> every feature of every language I have used. This is called experience...
> in the end you do know how NOT to do things:-)
>
> - some concepts are more robust, other less.
>>
>
> Sure. The use-case under discussion is about ONE session variable holding
> an expensive to compute security status which can be consulted by other
> functions. I think that probably one can have it right with both
> approaches, even if it is on the second try...
The robustness in not only about content, but about code maintenance,
possibility to quickly search errors or better don't do errors
>
>
> --
> Fabien.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2016-12-29 09:11:39 | Re: proposal: session server side variables |
| Previous Message | Fabien COELHO | 2016-12-29 08:57:28 | Re: proposal: session server side variables |