You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While UPDATE ... RETURNING and DELETE ... RETURNING require a SELECT privilege, INSERT ... RETURNING does not enforce that. It may look logical from the first glance, as there is usually no implicit cursor (that always exists for UPDATE/DELETE) and there's no OLD context for INSERT, so you can read only values from the row being inserted by yourself. However, some fields may be assigned implicitly (DEFAULT clause, GENERATED AS IDENTITY clause, BEFORE INSERT triggers) and the fact they can be read using the RETURNING clause looks like a minor security issue.
RETURNING is a non-standard extension, but the SQl specification includes <data change delta table> which is derived from rows changed by INSERT/UPDATE/DELETE statements, And it's explicitly specified that any column referenced in <data change delta table> require a SELECT permission on the target table for underlying INSERT/UPDATE/DELETE.
I suspect there may be a backward compatibility issue for those using INSERT ... RETURNING <generated PK> without a SELECT privilege granted. Thus backporting into v3 is questionable, I need other opinions in this regard.