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

portalcmds.c

Blame
    • Tom Lane's avatar
      b9527e98
      First phase of plan-invalidation project: create a plan cache management · b9527e98
      Tom Lane authored
      module and teach PREPARE and protocol-level prepared statements to use it.
      In service of this, rearrange utility-statement processing so that parse
      analysis does not assume table schemas can't change before execution for
      utility statements (necessary because we don't attempt to re-acquire locks
      for utility statements when reusing a stored plan).  This requires some
      refactoring of the ProcessUtility API, but it ends up cleaner anyway,
      for instance we can get rid of the QueryContext global.
      
      Still to do: fix up SPI and related code to use the plan cache; I'm tempted to
      try to make SQL functions use it too.  Also, there are at least some aspects
      of system state that we want to ensure remain the same during a replan as in
      the original processing; search_path certainly ought to behave that way for
      instance, and perhaps there are others.
      b9527e98
      History
      First phase of plan-invalidation project: create a plan cache management
      Tom Lane authored
      module and teach PREPARE and protocol-level prepared statements to use it.
      In service of this, rearrange utility-statement processing so that parse
      analysis does not assume table schemas can't change before execution for
      utility statements (necessary because we don't attempt to re-acquire locks
      for utility statements when reusing a stored plan).  This requires some
      refactoring of the ProcessUtility API, but it ends up cleaner anyway,
      for instance we can get rid of the QueryContext global.
      
      Still to do: fix up SPI and related code to use the plan cache; I'm tempted to
      try to make SQL functions use it too.  Also, there are at least some aspects
      of system state that we want to ensure remain the same during a replan as in
      the original processing; search_path certainly ought to behave that way for
      instance, and perhaps there are others.