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

trigger.c

Blame
    • Tom Lane's avatar
      c1b9ec24
      Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. · c1b9ec24
      Tom Lane authored
      conindid is the index supporting a constraint.  We can use this not only for
      unique/primary-key constraints, but also foreign-key constraints, which
      depend on the unique index that constrains the referenced columns.
      tgconstrindid is just copied from the constraint's conindid field, or is
      zero for triggers not associated with constraints.
      
      This is mainly intended as infrastructure for upcoming patches, but it has
      some virtue in itself, since it exposes a relationship that you formerly
      had to grovel in pg_depend to determine.  I simplified one information_schema
      view accordingly.  (There is a pg_dump query that could also use conindid,
      but I left it alone because it wasn't clear it'd get any faster.)
      c1b9ec24
      History
      Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid.
      Tom Lane authored
      conindid is the index supporting a constraint.  We can use this not only for
      unique/primary-key constraints, but also foreign-key constraints, which
      depend on the unique index that constrains the referenced columns.
      tgconstrindid is just copied from the constraint's conindid field, or is
      zero for triggers not associated with constraints.
      
      This is mainly intended as infrastructure for upcoming patches, but it has
      some virtue in itself, since it exposes a relationship that you formerly
      had to grovel in pg_depend to determine.  I simplified one information_schema
      view accordingly.  (There is a pg_dump query that could also use conindid,
      but I left it alone because it wasn't clear it'd get any faster.)