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

domains.c

Blame
    • Tom Lane's avatar
      991f3e5a
      Provide database object names as separate fields in error messages. · 991f3e5a
      Tom Lane authored
      This patch addresses the problem that applications currently have to
      extract object names from possibly-localized textual error messages,
      if they want to know for example which index caused a UNIQUE_VIOLATION
      failure.  It adds new error message fields to the wire protocol, which
      can carry the name of a table, table column, data type, or constraint
      associated with the error.  (Since the protocol spec has always instructed
      clients to ignore unrecognized field types, this should not create any
      compatibility problem.)
      
      Support for providing these new fields has been added to just a limited set
      of error reports (mainly, those in the "integrity constraint violation"
      SQLSTATE class), but we will doubtless add them to more calls in future.
      
      Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with
      additional hacking by Tom Lane.
      991f3e5a
      History
      Provide database object names as separate fields in error messages.
      Tom Lane authored
      This patch addresses the problem that applications currently have to
      extract object names from possibly-localized textual error messages,
      if they want to know for example which index caused a UNIQUE_VIOLATION
      failure.  It adds new error message fields to the wire protocol, which
      can carry the name of a table, table column, data type, or constraint
      associated with the error.  (Since the protocol spec has always instructed
      clients to ignore unrecognized field types, this should not create any
      compatibility problem.)
      
      Support for providing these new fields has been added to just a limited set
      of error reports (mainly, those in the "integrity constraint violation"
      SQLSTATE class), but we will doubtless add them to more calls in future.
      
      Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with
      additional hacking by Tom Lane.