|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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...
|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|