Re: [HACKERS] plPHP in core? - Mailing list pgsql-general

From Tom Lane
Subject Re: [HACKERS] plPHP in core?
Date
Msg-id 1561.1112422165@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] plPHP in core?  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [HACKERS] plPHP in core?  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: plPHP in core?  (Thomas Hallgren <thhal@mailblocks.com>)
Re: [HACKERS] plPHP in core?  (Hans-Jürgen Schönig <postgres@cybertec.at>)
List pgsql-general
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm not convinced that PLs are more tied to the core than say OpenFTS,
> and if we can't maintain that kind of thing externally, then this whole
> extension thing sounds like a failure to me.

It's *possible* to do it.  Whether it's a net savings of effort is
questionable.  For instance, I've had to hack plperl and plpgsql
over the past couple days to support OUT parameters, and the only
reason I didn't have to hack the other two standard PLs is that they
are a few features shy of a load already.  I'm pretty sure pl/r and
pl/java will need changes to support this feature too.  If they were in
core CVS then I'd consider it part of my responsibility to fix 'em
... but they aren't, so it isn't my problem, so it falls on Joe and
Thomas to get up to speed on what I've been doing and do likewise.
Is that really a win?

The point here is really that we keep finding reasons to, if not
flat-out change the interface to PLs, at least expand their
responsibilities.  Not to push it too hard, but we still have only
one PL with a validator procedure, which IIRC was your own addition
to that API.  How come they don't all have validators?

            regards, tom lane

pgsql-general by date:

Previous
From: Greg Stark
Date:
Subject: Re: Debugging deadlocks
Next
From: "Marc G. Fournier"
Date:
Subject: Re: [HACKERS] plPHP in core?