From: Michael Paquier <michael.paquier@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Jaime Casanova <jaime.casanova@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] generated columns
Date: Thu, 1 Feb 2018 14:03:48 +0900
Message-ID: <20180201050348.GA6398@paquier.xyz> (raw)
In-Reply-To: <20180131131804.GB1586@paquier.xyz>
References: <b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com>
<CAJGNTeOxeQPFpEr35PME4yLayRzP_wwzt70kFrPztSTWHf-HDA@mail.gmail.com>
<CAJGNTeM+MCjA4dBhAdjJ-vR_CwY3u65cCcc+KvnahzLHZjxjbw@mail.gmail.com>
<1bc948f8-3bab-6c54-50af-c0723a75b85f@2ndquadrant.com>
<20180116063546.GA3679@paquier.xyz>
<48502d9b-60c4-5b10-40a2-e34f562132b4@2ndquadrant.com>
<20180119051804.GC12826@paquier.xyz>
<2e3d5147-16f8-af0f-00ab-4c72cafc896f@2ndquadrant.com>
<20180131131804.GB1586@paquier.xyz>
On Wed, Jan 31, 2018 at 10:18:04PM +0900, Michael Paquier wrote:
> On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote:
>> On 1/19/18 00:18, Michael Paquier wrote:
>>> +SELECT a, c FROM gtest12; -- FIXME: should be allowed
>>> +ERROR: permission denied for function gf1
>>
>> This is quite hard to fix and I would like to leave this for a future
>> release.
>
> I have been looking at that case more closely again, and on the contrary
> I would advocate that your patch is doing the *right* thing. In short,
> if the generation expression uses a function and the user has only been
> granted access to read the values, it seems to me that it we should
> require that this user also has the right to execute the function. Would
> that be too user-unfriendly? I think that this could avoid mistakes
> about giving access to unwanted functions when willing to just give a
> SELECT right as the function could be doing more operations.
Attached is the SQL file I used with test cases for the review. I
forgot to attach it yesterday.
> Hm. Identity columns and default columns are part of rowtypes. STORED
> columns can alsobe part of a row type with little effort, so in order to
> be consistent with the all the existing behaviors, it seems to me that
> virtually-generated columns should be part of it as well. I have
> compiled in the attached SQL file how things behave with your
> patch. Only virtually-generated columns show a blank value.
The tests used are attached.
--
Michael
Attachments:
generated_cases.sql (application/x-sql, 1.8K) download
signature.asc (application/pgp-signature, 832B) download
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-hackers@postgresql.org
Cc: michael.paquier@gmail.com, peter.eisentraut@2ndquadrant.com, jaime.casanova@2ndquadrant.com
Subject: Re: [HACKERS] generated columns
In-Reply-To: <20180201050348.GA6398@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox