MIME-Version: 1.0
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <623395617.20171113141500@gf.microolap.com>
 <CAFj8pRDdS7ViLBJ6eA93u=C_x15EBv2deiNQDGkBS=LNrjzLLw@mail.gmail.com>
 <CAFj8pRBfb-GTZSHSRVTpMzGr26-7e-_RmOmRpmuk+xuDTgC=mA@mail.gmail.com>
 <28924bcc-9242-9798-e4e8-9d83cea3fef6@dalibo.com>
 <CAFj8pRBRxJ09ibuZT+KK3E+vc3-sXAz7HrbW3oVie7FwQRU-uQ@mail.gmail.com>
 <ae98027e-25a7-b229-ffec-b05d68162718@dalibo.com>
 <CAFj8pRATM44F1ugXxTn6aofxOa=3DZbqOJ17=EVyG+CEzsRQvw@mail.gmail.com>
 <CAFj8pRDnoA3J2RM=WZJdYBXEiJUOfDv-gyJmp81Pq93jmrBb5g@mail.gmail.com>
 <CAFj8pRCTz_CRez3vFo_Ta_m=KtOxBGHE9+T1QG3UgRbuURfzjA@mail.gmail.com>
 <CAFj8pRA_jZYuTRHEMsv8CnZLBqmnS5xRjcZh-uf0nBWA7WrzMA@mail.gmail.com>
 <alpine.DEB.2.21.1808211938510.11873@lancre>
In-Reply-To: <alpine.DEB.2.21.1808211938510.11873@lancre>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Tue, 21 Aug 2018 20:48:25 +0200
Message-ID: 
 <CAFj8pRCRUpNjX9Fb49SaADbRnCE69ndkOvtoeKxwvxetfJ8=kA@mail.gmail.com>
Subject: Re: [HACKERS] proposal: schema variables
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Gilles Darold <gilles.darold@dalibo.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000165a3a0573f679d4"
Precedence: bulk

--000000000000165a3a0573f679d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Fabien

Dne =C3=BAt 21. 8. 2018 19:56 u=C5=BEivatel Fabien COELHO <coelho@cri.ensmp=
.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 t=
o
> 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.
>

--000000000000165a3a0573f679d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hi Fabien<br><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">Dne =C3=BAt 21. 8. 2018 19:56 u=C5=BEivatel Fabien COELHO &lt;<a h=
ref=3D"mailto:coelho@cri.ensmp.fr">coelho@cri.ensmp.fr</a>&gt; napsal:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><br>
Hello Pavel,<br>
<br>
AFAICR, I had an objection on such new objects when you first proposed <br>
something similar in October 2016.<br>
<br>
Namely, if session variables are not transactional, they cannot be used to =
<br>
implement security related auditing features which were advertised as the <=
br>
motivating use case: an the audit check may fail on a commit because of a <=
br>
differed constraint, but the variable would keep its &quot;okay&quot; value=
 unduly, <br>
which would create a latent security issue, the audit check having failed <=
br>
but the variable saying the opposite.<br>
<br>
So my point was that they should be transactional by default, although I <b=
r>
would be ok with an option for having a voluntary non transactional <br>
version.<br>
<br>
Is this issue addressed somehow with this ?</blockquote></div></div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">1. I res=
pect your opinion, but I dont agree with it. Oracle, db2 has similar or ver=
y similar feature non transactional, and I didnt find any requests to chang=
e it.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">2. the proto=
type implementation was based on relclass items, and some transactional beh=
ave was possible. Peter E. had objections to this design and proposed own c=
atalog table. I did it. Now, the transactional behave is harder to implemen=
t, although it is not impossible. This patch is not small now, so I didnt i=
mplement it. I have a strong opinion so default behave have to be non trans=
actional.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Transactional =
variables significantly increases complexity of this patch, now is simple, =
because we can reset variable on drop variable command. Maybe I miss some s=
imply implementation, but I spent on it more than few days. Still, any coop=
eration are welcome.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Reg=
ards</div><div dir=3D"auto"><br></div><div dir=3D"auto">Pavel</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div=
><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<br>
-- <br>
Fabien.<br>
</blockquote></div></div></div>

--000000000000165a3a0573f679d4--