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
