From: | Mark Wong <markwkm(at)gmail(dot)com> |
---|---|
To: | 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-07 16:15:18 |
Message-ID: | Yk8OFtSyKDLLhjPW@workstation-mark-wong |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 07, 2022 at 10:30:13AM -0400, chap(at)anastigmatix(dot)net wrote:
> On 2022-04-06 16:44, Mark Wong wrote:
> > I think I've applied all of these suggestions and attached a new patch.
>
> That looks good to me, though I wonder about the pfree(source).
> In the simplest case of a PL that uses no advance compilation or
> augmentation step, the Code Execution block might naturally refer
> to source, so perhaps the example boilerplate shouldn't include
> a pfree that needs to be removed in that case.
>
> In fact, I wonder about the need for any retail pfree()s here. Those
> added in this patch are the only ones in plsample.c. They are small
> allocations, and maybe it would both streamline the example to leave
> out the pfree calls, and be an illustration of best practice in letting
> the memory context machinery handle all the deallocation at once, where
> there isn't a special need to free something, like an especially large
> allocation, at retail.
Thanks, I've attached v4.
I've removed all of the pfree()'s and added an elog(DEBUG1) for source
to quiet a compiler warning about source's lack of use. :) (Was that a
good way?)
Regards,
Mark
Attachment | Content-Type | Size |
---|---|---|
plsample-trigger-v4.patch | text/plain | 9.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-04-07 16:15:44 | Re: should vacuum's first heap pass be read-only? |
Previous Message | chap | 2022-04-07 16:00:49 | test/isolation/expected/stats_1.out broken for me |