Re: Three weeks left until feature freeze

On Wed, Jul 12, 2006 at 10:14:53AM -0400, Andrew Dunstan wrote:
> Hannu Krosing wrote:
> >Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
> >
> >>>There should be a Procedural Language section on pgfoundry for all of the
> >>>PLs, IMHO, and a README in contrib within core that points to it
> >>>(README.procedural_languages, if nothing else) ...
> >>>
> >>I thought that the general consensus was that only plpgsql ought to be in
> >>core, the rest should be independent projects.
> >>
> >
> >That would be doable if we had a stable language API.
> >
> >As i understand it, we still dont. And even more - most of the changes
> >to API come frome the needs of those (new) languages
> >
> >
>
> There is in effect no API at all, other than what is available to all
> backend modules. If someone wants to create an API which will be both
> sufficiently stable and sufficiently complete to meet the needs of the
> various PLs (especially, as Hannu rightly observes, any new PLs that
> come along) then we can revisit this question. Until then I suggest
> that it is at best premature. I am not even sure such a thing is
> actually possible.
>
> Also there is this: speaking as someone who actually does some work in
> this area, I very much appreciate having the eagle eyes of people like
> Tom, Neil and Joe on what's going on, and keeping things on the straight
> and narrow. I at least would feel lots less comfortable about
> maintaining things without such help.

If I've caught the right threads... Informix IUS and Illustra had a language
manager module which facilitated function resolution and argument marshalling
ala SQL and then made the calls to each language in the same API/function
call format. Usually I do not like added layers, however, this layer could
and should be used to deal with function resolution, type coercion, domains,
etc, which is the SQL side. The language itself would have predefined ways
of getting arguments and returning data. I'm not sure if this approach
would work with the bonus extras on plpgsql, but it should.

If anyone wants to pursue this area, please include me on the discussion
and I can try to provide information regarding the other implementation.

--elein

>
> The Postgres hacker community is small. I am not sure there is an
> adequate pool of people who will maintain the momentum of each
> sub-project that we might choose to orphan. If we had thousands of eager
> code cutters it might be different, but we don't, really.
>
> cheers
>
> andrew
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>