Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

cluster.c

Blame
    • Robert Haas's avatar
      74a1d4fe
      Improve behavior of concurrent rename statements. · 74a1d4fe
      Robert Haas authored
      Previously, renaming a table, sequence, view, index, foreign table,
      column, or trigger checked permissions before locking the object, which
      meant that if permissions were revoked during the lock wait, we would
      still allow the operation.  Similarly, if the original object is dropped
      and a new one with the same name is created, the operation will be allowed
      if we had permissions on the old object; the permissions on the new
      object don't matter.  All this is now fixed.
      
      Along the way, attempting to rename a trigger on a foreign table now gives
      the same error message as trying to create one there in the first place
      (i.e. that it's not a table or view) rather than simply stating that no
      trigger by that name exists.
      
      Patch by me; review by Noah Misch.
      74a1d4fe
      History
      Improve behavior of concurrent rename statements.
      Robert Haas authored
      Previously, renaming a table, sequence, view, index, foreign table,
      column, or trigger checked permissions before locking the object, which
      meant that if permissions were revoked during the lock wait, we would
      still allow the operation.  Similarly, if the original object is dropped
      and a new one with the same name is created, the operation will be allowed
      if we had permissions on the old object; the permissions on the new
      object don't matter.  All this is now fixed.
      
      Along the way, attempting to rename a trigger on a foreign table now gives
      the same error message as trying to create one there in the first place
      (i.e. that it's not a table or view) rather than simply stating that no
      trigger by that name exists.
      
      Patch by me; review by Noah Misch.