Supporting $n parameters in new syntax

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Supporting $n parameters in new syntax
Date: 2021-05-18 22:00:24
Message-ID: CA+renyU5dpNqmvTKYQrg=G6fQA3Fp5LQhyAg_d-w_YqkRCoyMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello hackers,

I'm wrapping up a patch that adds SQL:2011 FOR PORTION OF syntax and
then uses it to implement CASCADE in temporal foreign keys. The FKs
are implemented as triggers, like ordinary FKs, and the trigger
function makes a call through SPI that does `UPDATE %s FOR PORTION OF
%s FROM $%d TO $%d`. But I suspect I'm missing something in the
analyze/rewriting phase, because I get this error:

ERROR: no value found for parameter 1

That's coming from ExecEvalParamExtern in executor/execExprInterp.c.

If I hardcode some dates instead, the query works (even if I use the
same parameters elsewhere). Does anyone have any hints what I may be
missing? Any suggestions for some other syntax to consult as an
example (e.g. ON CONFLICT DO UPDATE)?

In gram.y I parse the phrase like this:

FOR PORTION OF ColId FROM a_expr TO a_expr

Then in the analysis phase I do this:

/*
* Build a range from the FROM ... TO .... bounds.
* This should give a constant result, so we accept functions like NOW()
* but not column references, subqueries, etc.
*
* It also permits MINVALUE and MAXVALUE like declarative partitions.
*/
Node *target_start = transformForPortionOfBound(forPortionOf->target_start);
Node *target_end = transformForPortionOfBound(forPortionOf->target_end);
FuncCall *fc = makeFuncCall(SystemFuncName(range_type_name),
list_make2(target_start, target_end),
COERCE_EXPLICIT_CALL,
forPortionOf->range_name_location);
result->targetRange = transformExpr(pstate, (Node *) fc,
EXPR_KIND_UPDATE_PORTION);

(transformForPortionOfBound just handles MIN/MAXVALUE, and for
targetRange I feed the bounds into a range type constructor to use
later.)

I was hoping that transformExpr would do everything I need re
identifying parameters, but maybe there is something else in a later
phase?

Thanks,
Paul

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-05-18 23:02:56 Re: PG 14 release notes, first draft
Previous Message Tom Lane 2021-05-18 21:51:00 Re: pgbench test failing on 14beta1 on Debian/i386