Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fsotR-0003BA-Jd for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Aug 2018 12:39:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fsotQ-0008Qb-69 for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Aug 2018 12:39:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fsotP-0008QU-Qn for pgsql-hackers@lists.postgresql.org; Thu, 23 Aug 2018 12:39:16 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fsotK-0005wo-6w for pgsql-hackers@lists.postgresql.org; Thu, 23 Aug 2018 12:39:15 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id A630521C26DE for ; Thu, 23 Aug 2018 15:39:08 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.93] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 7CB3021C26DA for ; Thu, 23 Aug 2018 15:39:08 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1535027948; bh=YauusRUMXF/ERwVADkUvboyQob1hEiIjkEzZacHd4ss=; h=Subject:To:References:From:Date:In-Reply-To; b=kQaPRGNjVkWcVxE1d1wW3yulV4XLsdTXAfHdBonVCPqhhXWGlSGFG1peLBJ7drVcz brlN2eQ/Qa1YjfXwnlCtGCPPEa6o2l19NCR84xS5orgLDcZ4JNSIxojhiRXklbZw1X E++4C86o9//X3GGsi2bFZoprljdpyMEOzjeYC8dg= Subject: Re: [HACKERS] proposal: schema variables To: pgsql-hackers@lists.postgresql.org References: <28924bcc-9242-9798-e4e8-9d83cea3fef6@dalibo.com> From: Pavel Luzanov Message-ID: <66454695-1317-feb8-766a-a8daa75fde06@postgrespro.ru> Date: Thu, 23 Aug 2018 15:39:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: ru-RU List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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