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_node.c

Blame
    • Tom Lane's avatar
      fb5d0580
      Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my · fb5d0580
      Tom Lane authored
      recent proposal.  As proof of concept, remove knowledge of Params from the
      core parser, arranging for them to be handled entirely by parser hook
      functions.  It turns out we need an additional hook for that --- I had
      forgotten about the code that handles inferring a parameter's type from
      context.
      
      This is a preliminary step towards letting plpgsql handle its variables
      through parser hooks.  Additional work remains to be done to expose the
      facility through SPI, but I think this is all the changes needed in the core
      parser.
      fb5d0580
      History
      Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my
      Tom Lane authored
      recent proposal.  As proof of concept, remove knowledge of Params from the
      core parser, arranging for them to be handled entirely by parser hook
      functions.  It turns out we need an additional hook for that --- I had
      forgotten about the code that handles inferring a parameter's type from
      context.
      
      This is a preliminary step towards letting plpgsql handle its variables
      through parser hooks.  Additional work remains to be done to expose the
      facility through SPI, but I think this is all the changes needed in the core
      parser.