Re: [HACKERS] plPHP in core?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] plPHP in core?
Дата
Msg-id 1561.1112422165@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] plPHP in core?  (Peter Eisentraut <peter_e@gmx.net>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Debugging deadlocks
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: [HACKERS] plPHP in core?