From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | mlw <markw(at)mohawksoft(dot)com> |
Cc: | Vincent AE Scott <vince(at)codex(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: external function proposal for 7.2 |
Date: | 2000-12-13 05:20:20 |
Message-ID: | 8234.976684820@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
mlw <markw(at)mohawksoft(dot)com> writes:
> I just have to find where I call the exit function.
That will be the hard part.
FmgrInfo is not currently considered a durable data structure, and I
think you will be in for grief if you try to make any guarantees about
what will happen when one disappears. If you need a cleanup proc to
be called, I'd suggest looking into registering it to be called at
query completion and/or transaction cleanup/abort, as needed.
Most of the sorts of resources you might need to clean up already have
cleanup mechanisms, so it's not entirely clear that you even *need*
a cleanup proc. Maybe a different way to say that is that Postgres
already has a pretty well-defined cleanup philosophy, and it's geared
to particular resources (memory, open files, etc) not to individual
called functions. You should consider swimming with that tide rather
than against it.
I have no objection to adding another field to FmgrInfo for the callee's
use, if you can show an example or two where it'd be useful. I'm only
concerned about the callback-on-delete part. That sounds like a recipe
for fragility...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2000-12-13 05:31:38 | C function proposal redux |
Previous Message | Christopher Kings-Lynne | 2000-12-13 05:02:17 | Creating a 'SET' type |