From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [HACKERS] proposal: schema variables |
Date: | 2018-08-21 18:48:25 |
Message-ID: | CAFj8pRCRUpNjX9Fb49SaADbRnCE69ndkOvtoeKxwvxetfJ8=kA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Hi Fabien
Dne út 21. 8. 2018 19:56 uživatel Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
napsal:
>
> Hello Pavel,
>
> AFAICR, I had an objection on such new objects when you first proposed
> something similar in October 2016.
>
> Namely, if session variables are not transactional, they cannot be used to
> implement security related auditing features which were advertised as the
> motivating use case: an the audit check may fail on a commit because of a
> differed constraint, but the variable would keep its "okay" value unduly,
> which would create a latent security issue, the audit check having failed
> but the variable saying the opposite.
>
> So my point was that they should be transactional by default, although I
> would be ok with an option for having a voluntary non transactional
> version.
>
> Is this issue addressed somehow with this ?
1. I respect your opinion, but I dont agree with it. Oracle, db2 has
similar or very similar feature non transactional, and I didnt find any
requests to change it.
2. the prototype implementation was based on relclass items, and some
transactional behave was possible. Peter E. had objections to this design
and proposed own catalog table. I did it. Now, the transactional behave is
harder to implement, although it is not impossible. This patch is not small
now, so I didnt implement it. I have a strong opinion so default behave
have to be non transactional.
Transactional variables significantly increases complexity of this patch,
now is simple, because we can reset variable on drop variable command.
Maybe I miss some simply implementation, but I spent on it more than few
days. Still, any cooperation are welcome.
Regards
Pavel
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Shawn Debnath | 2018-08-21 18:48:36 | Re: Proposal: SLRU to Buffer Cache |
Previous Message | Andres Freund | 2018-08-21 18:10:05 | Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) |
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2018-08-22 07:00:45 | Re: [HACKERS] proposal: schema variables |
Previous Message | Fabien COELHO | 2018-08-21 17:55:57 | Re: [HACKERS] proposal: schema variables |