Refactoring simplify_function (was: Caching constant stable expressions) - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Refactoring simplify_function (was: Caching constant stable expressions)
Date
Msg-id CABRT9RBaE+ZNrJBVdovnbCN_P2Z_gUJow4UtZMOjchov_m_DuA@mail.gmail.com
Whole thread Raw
Responses Re: Refactoring simplify_function (was: Caching constant stable expressions)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi list,

Per Tom's request, I split out this refactoring from my CacheExpr patch.

Basically I'm just centralizing the eval_const_expressions_mutator()
call on function arguments, from multiple different places to a single
location. Without this, it would be a lot harder to implement argument
caching logic in the CacheExpr patch.

The old call tree goes like:
case T_FuncExpr:
-> eval_const_expressions_mutator(args)
-> simplify_function
   -> reorder_function_arguments
       -> eval_const_expressions_mutator(args)
   -> add_function_defaults
       -> eval_const_expressions_mutator(args)

New call tree:
case T_FuncExpr:
-> simplify_function
   -> simplify_copy_function_arguments
      -> reorder_function_arguments
      -> add_function_defaults
   -> eval_const_expressions_mutator(args)

Assumptions being made:
* The code didn't depend on expanding existing arguments before adding defaults
* operator calls don't need to expand default arguments -- it's
currently impossible to CREATE OPERATOR with a function that has
unspecified arguments

Other changes:
* simplify_function no longer needs a 'bool has_named_args' argument
(it finds out itself).
* I added 'bool mutate_args' in its place, since some callers need to
mutate args beforehand.
* reorder_function_arguments no longer needs to keep track of which
default args were added.

Regards,
Marti

Attachment

pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: Review of pg_archivecleanup -x option patch
Next
From: Hans-Jürgen Schönig
Date:
Subject: Re: pg_prewarm