Replace SQLValueFunction by COERCE_SQL_SYNTAX

This switch impacts 9 patterns related to a SQL-mandated special syntax
for function calls:
- LOCALTIME [ ( typmod ) ]
- LOCALTIMESTAMP [ ( typmod ) ]
- CURRENT_TIME [ ( typmod ) ]
- CURRENT_TIMESTAMP [ ( typmod ) ]
- CURRENT_DATE

Five new entries are added to pg_proc to compensate the removal of
SQLValueFunction to provide backward-compatibility and making this
change transparent for the end-user (for example for the attribute
generated when a keyword is specified in a SELECT or in a FROM clause
without an alias, or when specifying something else than an Iconst to
the parser).

The parser included a set of checks coming from the files in charge of
holding the C functions used for the SQLValueFunction calls (as of
transformSQLValueFunction()), which are now moved within each function's
execution path, so this reduces the dependencies between the execution
and the parsing steps.  As of this change, all the SQL keywords use the
same paths for their work, relying only on COERCE_SQL_SYNTAX.  Like
fb32748, no performance difference has been noticed, while the perf
profiles get reduced with ExecEvalSQLValueFunction() gone.

Bump catalog version.

Reviewed-by: Corey Huinker, Ted Yu
Discussion: https://postgr.es/m/[email protected]

1 files changed, 0 insertions, 46 deletions

diff --git a/src/backend/executor/execExprInterp.c b/src/backend/executor/execExprInterp.c
index 6ebf5c287ea..1dab2787b79 100644
--- a/src/backend/executor/execExprInterp.c
+++ b/src/backend/executor/execExprInterp.c
@@ -452,7 +452,6 @@ ExecInterpExpr(ExprState *state, ExprContext *econtext, bool *isnull)
 		&&CASE_EEOP_DISTINCT,
 		&&CASE_EEOP_NOT_DISTINCT,
 		&&CASE_EEOP_NULLIF,
-		&&CASE_EEOP_SQLVALUEFUNCTION,
 		&&CASE_EEOP_CURRENTOFEXPR,
 		&&CASE_EEOP_NEXTVALUEEXPR,
 		&&CASE_EEOP_ARRAYEXPR,
@@ -1301,17 +1300,6 @@ ExecInterpExpr(ExprState *state, ExprContext *econtext, bool *isnull)
 			EEO_NEXT();
 		}
 
-		EEO_CASE(EEOP_SQLVALUEFUNCTION)
-		{
-			/*
-			 * Doesn't seem worthwhile to have an inline implementation
-			 * efficiency-wise.
-			 */
-			ExecEvalSQLValueFunction(state, op);
-
-			EEO_NEXT();
-		}
-
 		EEO_CASE(EEOP_CURRENTOFEXPR)
 		{
 			/* error invocation uses space, and shouldn't ever occur */
@@ -2490,40 +2478,6 @@ ExecEvalParamExtern(ExprState *state, ExprEvalStep *op, ExprContext *econtext)
 }
 
 /*
- * Evaluate a SQLValueFunction expression.
- */
-void
-ExecEvalSQLValueFunction(ExprState *state, ExprEvalStep *op)
-{
-	SQLValueFunction *svf = op->d.sqlvaluefunction.svf;
-
-	*op->resnull = false;
-
-	switch (svf->op)
-	{
-		case SVFOP_CURRENT_DATE:
-			*op->resvalue = DateADTGetDatum(GetSQLCurrentDate());
-			break;
-		case SVFOP_CURRENT_TIME:
-		case SVFOP_CURRENT_TIME_N:
-			*op->resvalue = TimeTzADTPGetDatum(GetSQLCurrentTime(svf->typmod));
-			break;
-		case SVFOP_CURRENT_TIMESTAMP:
-		case SVFOP_CURRENT_TIMESTAMP_N:
-			*op->resvalue = TimestampTzGetDatum(GetSQLCurrentTimestamp(svf->typmod));
-			break;
-		case SVFOP_LOCALTIME:
-		case SVFOP_LOCALTIME_N:
-			*op->resvalue = TimeADTGetDatum(GetSQLLocalTime(svf->typmod));
-			break;
-		case SVFOP_LOCALTIMESTAMP:
-		case SVFOP_LOCALTIMESTAMP_N:
-			*op->resvalue = TimestampGetDatum(GetSQLLocalTimestamp(svf->typmod));
-			break;
-	}
-}
-
-/*
  * Raise error if a CURRENT OF expression is evaluated.
  *
  * The planner should convert CURRENT OF into a TidScan qualification, or some