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-03-02 20:12:01 |
Message-ID: | Yh/PkdpVPbeydjC/@workstation-mark-wong |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 25, 2022 at 06:39:39PM +0000, Chapman Flack wrote:
> This patch is straightforward, does what it says, and passes the tests.
>
> Regarding the duplication of code between plsample_func_handler and
> plsample_trigger_handler, perhaps that's for the best for now, as 3554 in
> the same commitfest also touches plsample, so merge conflicts may be
> minimized by not doing more invasive refactoring.
>
> That would leave low-hanging fruit for a later patch that could refactor
> plsample to reduce the duplication (maybe adding a validator at the same
> time? That would also duplicate some of the checks in the existing handlers.)
>
> I am not sure that structuring the trigger handler with separate compile and
> execute steps is worth the effort for a simple example like plsample. The main
> plsample_func_handler is not so structured.
>
> It's likely that many real PLs will have some notion of compilation separate from
> execution. But those will also have logic to do the compilation only once, and
> somewhere to cache the result of that for reuse across calls, and those kinds of
> details might make plsample's basic skeleton more complex than needed.
>
> I know that in just looking at expected/plsample.out, I was a little distracted by
> seeing multiple "compile" messages for the same trigger function in the same
> session and wondering why that was.
>
> So maybe it would be simpler and less distracting to assume that the PL targeted
> by plsample is one that just has a simple interpreter that works from the source text.
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 that reduces the repetitiveness of the output...
Regards,
Mark
Attachment | Content-Type | Size |
---|---|---|
plsample-trigger-v2.patch | text/plain | 10.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2022-03-02 20:26:32 | Re: Proposal: Support custom authentication methods using hooks |
Previous Message | Andres Freund | 2022-03-02 20:09:42 | Re: Proposal: Support custom authentication methods using hooks |