Skip site navigation (1) Skip section navigation (2)

SRF patch (was Re: [HACKERS] troubleshooting pointers)

From: Joe Conway <mail(at)joeconway(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date: 2002-05-11 01:45:27
Message-ID: 3CDC77B7.3000807@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Um.  I don't like that; it assumes not only that ExecutorEnd is the only
> kind of callback needed, but also that there is at most one function
> per ExprContext that needs a shutdown callback.  Neither of these
> assumptions hold water IMO.
> 
> The design I had in mind was more like this: add to ExprContext a list
> header field pointing to a list of structs along the lines of
> 
> 	struct exprcontext_callback {
> 		struct exprcontext_callback *next;
> 		void (*function) (Datum);
> 		Datum arg;
> 	}
> 
> and then call each specified function with given argument during
> FreeExprContext.  Probably ought to be careful to do that in reverse
> order of registration.  We'd also need to invent a RescanExprContext
> operation to call the callbacks during a Rescan.  The use of Datum
> (and not, say, void *) as PG's standard callback arg type was settled on
> some time ago --- originally for on_proc_exit IIRC --- and seems to have
> worked well enough.

Here's the patch, per my post to HACKERS.

It builds cleanly on my dev box, and passes all regression tests.

Thanks,

Joe


Attachment: srf.2002.05.10.1.patch.gz
Description: application/x-gzip (23.9 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-05-11 02:07:36
Subject: Re: troubleshooting pointers
Previous:From: Joe ConwayDate: 2002-05-11 01:40:57
Subject: Re: troubleshooting pointers

pgsql-patches by date

Next:From: Tom LaneDate: 2002-05-11 02:07:36
Subject: Re: troubleshooting pointers
Previous:From: Joe ConwayDate: 2002-05-11 01:40:57
Subject: Re: troubleshooting pointers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group