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
      a874fe7b
      Refactor the executor's API to support data-modifying CTEs better. · a874fe7b
      Tom Lane authored
      The originally committed patch for modifying CTEs didn't interact well
      with EXPLAIN, as noted by myself, and also had corner-case problems with
      triggers, as noted by Dean Rasheed.  Those problems show it is really not
      practical for ExecutorEnd to call any user-defined code; so split the
      cleanup duties out into a new function ExecutorFinish, which must be called
      between the last ExecutorRun call and ExecutorEnd.  Some Asserts have been
      added to these functions to help verify correct usage.
      
      It is no longer necessary for callers of the executor to call
      AfterTriggerBeginQuery/AfterTriggerEndQuery for themselves, as this is now
      done by ExecutorStart/ExecutorFinish respectively.  If you really need to
      suppress that and do it for yourself, pass EXEC_FLAG_SKIP_TRIGGERS to
      ExecutorStart.
      
      Also, refactor portal commit processing to allow for the possibility that
      PortalDrop will invoke user-defined code.  I think this is not actually
      necessary just yet, since the portal-execution-strategy logic forces any
      non-pure-SELECT query to be run to completion before we will consider
      committing.  But it seems like good future-proofing.
      a874fe7b
      History
      Refactor the executor's API to support data-modifying CTEs better.
      Tom Lane authored
      The originally committed patch for modifying CTEs didn't interact well
      with EXPLAIN, as noted by myself, and also had corner-case problems with
      triggers, as noted by Dean Rasheed.  Those problems show it is really not
      practical for ExecutorEnd to call any user-defined code; so split the
      cleanup duties out into a new function ExecutorFinish, which must be called
      between the last ExecutorRun call and ExecutorEnd.  Some Asserts have been
      added to these functions to help verify correct usage.
      
      It is no longer necessary for callers of the executor to call
      AfterTriggerBeginQuery/AfterTriggerEndQuery for themselves, as this is now
      done by ExecutorStart/ExecutorFinish respectively.  If you really need to
      suppress that and do it for yourself, pass EXEC_FLAG_SKIP_TRIGGERS to
      ExecutorStart.
      
      Also, refactor portal commit processing to allow for the possibility that
      PortalDrop will invoke user-defined code.  I think this is not actually
      necessary just yet, since the portal-execution-strategy logic forces any
      non-pure-SELECT query to be run to completion before we will consider
      committing.  But it seems like good future-proofing.