Re: external function proposal for 7.2 - Mailing list pgsql-hackers

From mlw
Subject Re: external function proposal for 7.2
Date
Msg-id 3A36C5C0.F3EC7DEB@mohawksoft.com
Whole thread Raw
In response to external function proposal for 7.2  (mlw <markw@mohawksoft.com>)
Responses Re: external function proposal for 7.2
List pgsql-hackers
Vincent AE Scott wrote:
> 
> As a lurker on the list this post caught my eye somewhat.  I think this
> would be excellent functionality to have in postgres, i was considering
> doing something like this in a non intruse manner, by manipulating
> _init() and _fini functions of shared libraries.  But what you have
> described below is a much better interface.  In particular i was looking
> at a way of getting async notifications when a row had been inserted, and
> pasing out to my other applications enough data, to be able to query back
> in for the complete row.
> 
> The ability to have an init/exit for an external function would be a big
> win, you could even have the init() create a thread for passing results
> to, and performing what ever voodoo magic you wanted.
> 
> i'll go back to lurking and listening now.

I did some code spelunking today. It will not be easy, but I think it is
quite doable. Currently, in the code, a function pointer is passed
around. If I resurrect some of the "old" C code a bit, and do some
merging with the new code we could do it. I just have to find where I
call the exit function.

As far as I can see, the code passes around a function pointer, but
seems to mostly call a small number of localized functions to dispatch
the call. So, I was thinking, rather than pass the function, why not
pass the structure? The old C code stuff does this, why not keep it
around, and pass around the finfo struct instead? and call
(*finfo->funct)(args)?

> 
> On Tue, 12 Dec 2000, mlw wrote:
> 
> > I think the newC function idea is pretty good, however, what would be
> > great is just one more step of protocol, perhaps an API verson 2 or 3:
> >
> > One thing than makes writing a non-trivial function a bit problematic,
> > and perhaps even less efficient, is that the function does not know when
> > it is first run and when it is finished, and there is no facility to
> > manage contextual information. This limits external functons having to
> > be  fairly simple, or overly complex.
> >
> > I propose that when the newC structure is allocated that a function
> > specific "Init" function be called, and when the structure is being
> > freed, calling a "Exit" function. The new C structure should also have a
> > void pointer that allows persistent information to be passed around.
> >
> > typedef struct
> > {
> >     FmgrInfo   *flinfo;         /* ptr to lookup info used for this call
> > */
> >     Node       *context;        /* pass info about context of call */
> >     Node       *resultinfo;     /* pass or return extra info about
> > result */
> >     bool        isnull;         /* function must set true if result is
> > NULL */
> >     short       nargs;          /* # arguments actually passed */
> >     Datum       arg[FUNC_MAX_ARGS];  /* Arguments passed to function */
> >     bool        argnull[FUNC_MAX_ARGS];  /* T if arg[i] is actually NULL
> > */
> >
> >     void *    userparam;    /* to be used by he function */
> >
> > } FunctionCallInfoData;
> > typedef FunctionCallInfoData* FunctionCallInfo;
> >
> > The userparam can be used to store data, or a count, or whatever.
> >
> > Datum function(PG_FUNCTION_ARGS) ;
> > bool function_Init(PG_FUNCTION_ARGS);
> > void function_Exit(PG_FUNCTION_ARGS);
> >
> > This protocol would make writing some really cool features much easier.
> > As a C++ guy, I could execute "new" at Init and "delete" at Exit. ;-)
> >
> >
> > Mark.
> >
> 
> PGP key:  http://codex.net/pgp/pgp.asc

-- 
http://www.mohawksoft.com


pgsql-hackers by date:

Previous
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: RFC C++ Interface
Next
From: Hannu Krosing
Date:
Subject: Need help with redefining locales