On Wed, Jun 7, 2017 at 12:19 PM, Peter Geoghegan <p...@bowt.ie> wrote: > On Tue, Jun 6, 2017 at 5:01 PM, Peter Geoghegan <p...@bowt.ie> wrote: >> Also, ISTM that the code within ENRMetadataGetTupDesc() probably >> requires more explanation, resource management wise. > > Also, it's not clear why it should be okay that the new type of > ephemeral RTEs introduced don't have permissions checks. There are > currently cases where the user cannot see data that they inserted > themselves (e.g., through RETURNING), on the theory that a before row > trigger might have modified the final contents of the tuple in a way > that the original inserter isn't supposed to know details about. > > As the INSERT docs say, "Use of the RETURNING clause requires SELECT > privilege on all columns mentioned in RETURNING". Similarly, the > excluded.* pseudo-relation requires select privilege (on the > corresponding target relation columns) in order to be usable by ON > CONFLICT DO UPDATE.
This is an interesting question and one that was mentioned here (near the bottom): https://www.postgresql.org/message-id/CACjxUsO%3DsquN2XbYBM6qLfS9co%3DbfGqQFxMfY%2BpjyAGKP_jpwQ%40mail.gmail.com I'm pretty sure that whatever applies to the NEW and OLD variables should also apply to the new table and old table, because the former are conceptually range variables over the latter. Without having checked either the standard or our behaviour for NEW and OLD, I'll bet you one internet point that they say we should apply the same access restrictions as the underlying table, and we don't. Am I wrong? -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
