Re: pljava revisited

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: pljava revisited
Дата
Msg-id 1071087067.1706.8094.camel@camel
обсуждение исходный текст
Ответ на Re: pljava revisited  (Jan Wieck <JanWieck@Yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pljava revisited
Следующее
От: ow
Дата:
Сообщение: Re: pljava revisited