On 03/02/22 15:12, Mark Wong wrote:
> I've attached v2, which reduces the output:
>
> * Removing the notices for the text body, and the "compile" message.
> * Replaced the notice for "compile" message with a comment as a
> placeholder for where a compiling code or checking a cache may go.
> * Reducing the number of rows inserted into the table, thus reducing
> the number of notice messages about which code path is taken.
I think the simplifying assumption of a simple interpreted language allows
a lot more of this code to go away. I mean more or less that whole first
PG_TRY...PG_END_TRY block, which could be replaced with a comment saying
something like
The source text may be augmented here, such as by wrapping it as the
body of a function in the target language, prefixing a parameter list
with names like TD_name, TD_relid, TD_table_name, TD_table_schema,
TD_event, TD_when, TD_level, TD_NEW, TD_OLD, and args, using whatever
types in the target language are convenient. The augmented text can be
cached in a longer-lived memory context, or, if the target language uses
a compilation step, that can be done here, caching the result of the
compilation.
That would leave only the later PG_TRY block where the function gets
"executed". That could stay largely as is, but should probably also have
a comment within it, something like
Here the function (the possibly-augmented source text, or the result
of compilation if the target language uses such a step) should be
executed, after binding these values from the TriggerData struct to
the expected parameters.
That should make the example shorter and clearer, and preserve the output
tested by the regression test. Trying to show much more than that involves
assumptions about what the PL's target language syntax looks like, how its
execution engine works and parameters are bound, and so on, and that is
likely to just be distracting, IMV.
Regards,
-Chap
