Re: external function proposal for 7.2

Tom Lane wrote:
> 
> mlw <markw@mohawksoft.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.

I think making this structure durable with be fairly 'easy' assuming
that fmgr_info(...) is called only once prior to operations which
requires the function. If this is not the case, then you are 100% right. 

If my assumption is correct, and please correct me if I am wrong, then
all that should be needed to be done is allocate the structure at this
point, and pass it around as the function pointer, and just make sure
that it is always 'FunctionCallInvoke' that calls the function. 

Assuming all my assumptions are correct, (and I can't see how that is
possible ;-), I should also call the Init function at this time.

The big problem is calling the "Exit" function. I am sure that will not
be easily done, or even doable, but we can dream.

> 
> 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.

Believe me I understand what you are saying, but, I think Postgres, with
a few tweaks here and there, targeted at efficient extension mechanisms,
could blow away the DB market. I have harped on my text search engine, I
know, but I am not the only one that wants to do these sorts of things,
and it is discouraging how little information is available.

Making it easy for guys like me, to bring functionality into Posgres,
will make Postgres the hands down winner for so many projects that
otherwise would have to resort to using some crappy db library.

Postgres has it all, it has query language, presentation mechanisms,
ODBC, tools, etc. Rather than having to write an application around some
crappy db library, we could write a few neat functions in a powerful SQL
database.

I think a little focus on this area will pay off hugely.

> 
> 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...

Yes, this is a concern for sure, if it is a problem, then, absolutely,
it should be dropped.

-- 
http://www.mohawksoft.com