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
generated_cases.sql
Description: application/sql
signature.asc
Description: PGP signature
