Re: external function proposal for 7.2

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

In response to

Responses

Browse pgsql-hackers by date

  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