public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Pavel Luzanov <p.luzanov@postgrespro.ru>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] proposal: schema variables
Date: Thu, 23 Aug 2018 15:39:07 +0300
Message-ID: <66454695-1317-feb8-766a-a8daa75fde06@postgrespro.ru> (raw)
In-Reply-To: <alpine.DEB.2.21.1808231123050.31897@lancre>
References: <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@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>
<alpine.DEB.2.21.1808220831550.10677@lancre>
<CAFj8pRCyvx37Fnw6yHdscGbbGo_Ak3WdeKiZ6arFW8JTA099YA@mail.gmail.com>
<alpine.DEB.2.21.1808230927090.31897@lancre>
<CAFj8pRAcFv09qOcbr09c2AbwZ9DGw5Hs6rPcYoo7r9OLdWWB2A@mail.gmail.com>
<alpine.DEB.2.21.1808231123050.31897@lancre>
On 23.08.2018 12:46, Fabien COELHO wrote:
> I do not understand your point, as usual. I raise a factual issue
> about security, and you do not answer how this can be solved with your
> proposal, but appeal to argument of authority and declare your "strong
> opinion".
>
> I do not see any intrinsic opposition between having session objects
> and transactions. Nothing prevents a session object to be
> transactional beyond your willingness that it should not be.
>
> Now, I do expect all PostgreSQL features to be security-wise, whatever
> their scope.
>
> I do not think that security should be traded for "cheap & fast", esp
> as the sole use case for a feature is a security pattern that cannot
> be implemented securely with it. This appears to me as a huge
> contradiction, hence my opposition against this feature as proposed.
I can't to agree with your position.
Consider this example.
I want to record some inappropriate user actions to audit table and
rollback transaction.
But aborting transaction will also abort record to audit table.
So, do not use tables, becouse they have security implications.
This is very similar to your approach.
Schema variables is a very needed and important feature, but for others
purposes.
-----
Pavel Luzanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
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: p.luzanov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] proposal: schema variables
In-Reply-To: <66454695-1317-feb8-766a-a8daa75fde06@postgrespro.ru>
* 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