From: | Mark Wong <markwkm(at)gmail(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Konstantina Skovola <konskov(at)gmail(dot)com> |
Subject: | Re: trigger example for plsample |
Date: | 2022-04-06 20:44:28 |
Message-ID: | Yk37rCOPVFW3+EJh@workstation-mark-wong |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 10, 2022 at 06:36:44PM -0500, Chapman Flack wrote:
> 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.
I think I've applied all of these suggestions and attached a new patch.
Regards,
Mark
Attachment | Content-Type | Size |
---|---|---|
plsample-trigger-v3.patch | text/plain | 9.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-04-06 20:58:00 | Re: buildfarm failures, src/test/recovery |
Previous Message | Peter Geoghegan | 2022-04-06 20:14:04 | Re: New compiler warning from btree dedup code |