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

tablespace.c

Blame
    • Tom Lane's avatar
      5233dc15
      Improve consistency of error reporting in GUC assign_hook routines. Some · 5233dc15
      Tom Lane authored
      were reporting ERROR for interactive assignments and LOG for other cases,
      some were saying nothing for non-interactive cases, and a few did yet other
      things.  Make them use a new function GUC_complaint_elevel() to establish
      a reasonably uniform policy about how to report.  There are still a few
      edge cases such as assign_search_path(), but it's much better than before.
      Per gripe from Devrim Gunduz and subsequent discussion.
      
      As noted by Alvaro, it'd be better to fold these custom messages into the
      standard "invalid parameter value" complaint from guc.c, perhaps as the DETAIL
      field.  However that will require more redesign than seems prudent for 8.3.
      This is a relatively safe, low-impact change that we can afford to risk now.
      5233dc15
      History
      Improve consistency of error reporting in GUC assign_hook routines. Some
      Tom Lane authored
      were reporting ERROR for interactive assignments and LOG for other cases,
      some were saying nothing for non-interactive cases, and a few did yet other
      things.  Make them use a new function GUC_complaint_elevel() to establish
      a reasonably uniform policy about how to report.  There are still a few
      edge cases such as assign_search_path(), but it's much better than before.
      Per gripe from Devrim Gunduz and subsequent discussion.
      
      As noted by Alvaro, it'd be better to fold these custom messages into the
      standard "invalid parameter value" complaint from guc.c, perhaps as the DETAIL
      field.  However that will require more redesign than seems prudent for 8.3.
      This is a relatively safe, low-impact change that we can afford to risk now.