Re: pljava revisited - Mailing list pgsql-hackers

From Robert Treat
Subject Re: pljava revisited
Date
Msg-id 1071087067.1706.8094.camel@camel
Whole thread Raw
In response to Re: pljava revisited  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
On Wed, 2003-12-10 at 13:04, Jan Wieck wrote:
> Andrew Rawnsley wrote:
> 
> >> Other pl* (perl, python, tcl) languages have vanilla C glue code. 
> >> Might be better to stick to this. If you aren't using advanced C++ 
> >> features that shouldn't be too hard - well structured C can be just as 
> >> readable as well structured C++. At the very lowest level, about the 
> >> only things C++ buys you are the ability to declare variables in 
> >> arbitrary places, and // style comments.
> >>
> > 
> > Agreed. Given that the rest of the code base is C....I would imagine 
> > that the Powers that Be would frown a bit on merging
> > C++ code in, and relegate it to contrib for eternity...
> 
> It will probably have to live on GBorg right from the beginning anyway, 
> so "the Powers" might not care at all.
> 
> Thus far _all_ procedural languages are loadable modules. VM or not, I 
> don't see why this one would be any different. That also answers the "on 
> demand" question to some extent, doesn't it?
> 

Maybe I'm mixing concepts here, but didn't Joe Conway create the ability
to do pl module loading on demand or on connection creation via GUC? 
ISTR he needed this due to R's overhead. If so seems this could be
implemented both ways, with a recommendation on which is best to follow.
Speaking of plR, I'd recommend anyone interested in developing pl's,
whether enhancing old ones or creating new ones, to check out the plR
code on gborg, it was written recently and is pretty advanced.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pljava revisited
Next
From: ow
Date:
Subject: Re: pljava revisited