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

parse_relation.c

Blame
    • Robert Haas's avatar
      ba3d39c9
      Don't allow system columns in CHECK constraints, except tableoid. · ba3d39c9
      Robert Haas authored
      Previously, arbitray system columns could be mentioned in table
      constraints, but they were not correctly checked at runtime, because
      the values weren't actually set correctly in the tuple.  Since it
      seems easy enough to initialize the table OID properly, do that,
      and continue allowing that column, but disallow the rest unless and
      until someone figures out a way to make them work properly.
      
      No back-patch, because this doesn't seem important enough to take the
      risk of destabilizing the back branches.  In fact, this will pose a
      dump-and-reload hazard for those upgrading from previous versions:
      constraints that were accepted before but were not correctly enforced
      will now either be enforced correctly or not accepted at all.  Either
      could result in restore failures, but in practice I think very few
      users will notice the difference, since the use case is pretty
      marginal anyway and few users will be relying on features that have
      not historically worked.
      
      Amit Kapila, reviewed by Rushabh Lathia, with doc changes by me.
      ba3d39c9
      History
      Don't allow system columns in CHECK constraints, except tableoid.
      Robert Haas authored
      Previously, arbitray system columns could be mentioned in table
      constraints, but they were not correctly checked at runtime, because
      the values weren't actually set correctly in the tuple.  Since it
      seems easy enough to initialize the table OID properly, do that,
      and continue allowing that column, but disallow the rest unless and
      until someone figures out a way to make them work properly.
      
      No back-patch, because this doesn't seem important enough to take the
      risk of destabilizing the back branches.  In fact, this will pose a
      dump-and-reload hazard for those upgrading from previous versions:
      constraints that were accepted before but were not correctly enforced
      will now either be enforced correctly or not accepted at all.  Either
      could result in restore failures, but in practice I think very few
      users will notice the difference, since the use case is pretty
      marginal anyway and few users will be relying on features that have
      not historically worked.
      
      Amit Kapila, reviewed by Rushabh Lathia, with doc changes by me.