From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] generated columns |
Date: | 2018-02-01 05:03:48 |
Message-ID: | 20180201050348.GA6398@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
generated_cases.sql | application/x-sql | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-02-01 05:35:59 | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |
Previous Message | Marina Polyakova | 2018-02-01 05:01:48 | Re: WIP Patch: Precalculate stable functions, infrastructure v1 |