Re: [HACKERS] generated columns

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