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

create_function.sgml

Blame
    • Tom Lane's avatar
      1fb57af9
      Create the infrastructure for planner support functions. · 1fb57af9
      Tom Lane authored
      Rename/repurpose pg_proc.protransform as "prosupport".  The idea is
      still that it names an internal function that provides knowledge to
      the planner about the behavior of the function it's attached to;
      but redesign the API specification so that it's not limited to doing
      just one thing, but can support an extensible set of requests.
      
      The original purpose of simplifying a function call is handled by
      the first request type to be invented, SupportRequestSimplify.
      Adjust all the existing transform functions to handle this API,
      and rename them fron "xxx_transform" to "xxx_support" to reflect
      the potential generalization of what they do.  (Since we never
      previously provided any way for extensions to add transform functions,
      this change doesn't create an API break for them.)
      
      Also add DDL and pg_dump support for attaching a support function to a
      user-defined function.  Unfortunately, DDL access has to be restricted
      to superusers, at least for now; but seeing that support functions
      will pretty much have to be written in C, that limitation is just
      theoretical.  (This support is untested in this patch, but a follow-on
      patch will add cases that exercise it.)
      
      Discussion: https://postgr.es/m/15193.1548028093@sss.pgh.pa.us
      1fb57af9
      History
      Create the infrastructure for planner support functions.
      Tom Lane authored
      Rename/repurpose pg_proc.protransform as "prosupport".  The idea is
      still that it names an internal function that provides knowledge to
      the planner about the behavior of the function it's attached to;
      but redesign the API specification so that it's not limited to doing
      just one thing, but can support an extensible set of requests.
      
      The original purpose of simplifying a function call is handled by
      the first request type to be invented, SupportRequestSimplify.
      Adjust all the existing transform functions to handle this API,
      and rename them fron "xxx_transform" to "xxx_support" to reflect
      the potential generalization of what they do.  (Since we never
      previously provided any way for extensions to add transform functions,
      this change doesn't create an API break for them.)
      
      Also add DDL and pg_dump support for attaching a support function to a
      user-defined function.  Unfortunately, DDL access has to be restricted
      to superusers, at least for now; but seeing that support functions
      will pretty much have to be written in C, that limitation is just
      theoretical.  (This support is untested in this patch, but a follow-on
      patch will add cases that exercise it.)
      
      Discussion: https://postgr.es/m/15193.1548028093@sss.pgh.pa.us