public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Fabien COELHO <coelho@cri.ensmp.fr>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Gilles Darold <gilles.darold@dalibo.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [HACKERS] proposal: schema variables
Date: Wed, 22 Aug 2018 09:00:45 +0200 (CEST)
Message-ID: <alpine.DEB.2.21.1808220831550.10677@lancre> (raw)
In-Reply-To: <CAFj8pRCRUpNjX9Fb49SaADbRnCE69ndkOvtoeKxwvxetfJ8=kA@mail.gmail.com>
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>
<CAFj8pRCRUpNjX9Fb49SaADbRnCE69ndkOvtoeKxwvxetfJ8=kA@mail.gmail.com>
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.
The argument of authority that "X does it like that" is not a valid answer
to my technical objection about security implications of this feature.
> 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.
"It is harder to implement" does not look like a valid answer either.
> I have a strong opinion so default behave have to be non transactional.
The fact that you have a "strong opinion" does not really answer my
objection. Moreover, I said that I would be ok with a non transactional
option, provided that a default transactional is available.
> 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.
"It is simpler to implement this way" is not an answer either, especially
as you said that it could have been on point 2.
As I do not see any clear answer to my objection about security
implications, I understand that it is not addressed by this patch.
At the bare minimum, if this feature ever made it as is, I think that a
clear caveat must be included in the documentation about not using it for
any security-related purpose.
Also, I'm not really sure how useful such a non-transactional object can
be for other purposes: the user should take into account that the
transaction may fail and the value of the session variable be inconsistent
as a result. Sometimes it may not matter, but if it matters there is no
easy way around the fact.
--
Fabien.
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: coelho@cri.ensmp.fr, pavel.stehule@gmail.com, gilles.darold@dalibo.com, pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] proposal: schema variables
In-Reply-To: <alpine.DEB.2.21.1808220831550.10677@lancre>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox