On Tue, Jun 6, 2017 at 8: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.
Why so? I'm not saying you're wrong, but I don't see what's confusing about the status quo. I may be missing something important. > 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. Right, but the trigger has to be have been created by someone who has TRIGGER permission on the table, and such an individual can trivially steal the entire contents of every table row subsequently touched by any DML statement by installing a FOR-EACH-ROW trigger that records the contents of the tuple someplace. So the fact that they can now also do that by installing a FOR-EACH-STATEMENT trigger doesn't seem to be expanding the vulnerability surface. If anything, the new thing gives trigger-creators less power than they have already, since the tuplestore only lets you see what tuples were modified, whereas a before-row trigger could block or alter the modifications. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
