Re: [HACKERS] proposal: schema variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
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 17:55:57
Message-ID: alpine.DEB.2.21.1808211938510.11873@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance


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 version?

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2018-08-21 18:03:26 Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
Previous Message Andres Freund 2018-08-21 17:54:29 Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Browse pgsql-performance by date

  From Date Subject
Next Message Pavel Stehule 2018-08-21 18:48:25 Re: [HACKERS] proposal: schema variables
Previous Message Jeremy Schneider 2018-08-20 22:14:49 Re: Guideline To Resolve LWLock:SubtransControlLock