Hannu Krosing <hannu@krosing.net> writes:
> On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
>> These are all excellent points but I think the real problem here is:
>> There is nothing that requires pl/proxy to be in core.
> AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to be
> in core either.
True, but I think it's a good idea to have at least one such in core,
as a prototype to help us track the issues associated with loading a
large third-party library along with a PL. The fact that we have three
is historical, but on the other hand I believe we've seen distinct
issues crop up from each one, so maybe only one isn't enough either.
> Actually, I think that being an independent language / postgresql
> extension tool, pl/proxy is _more_ fit to be in core than external
> language adapters.
It teaches us nothing about connecting to outside code, though.
> And it would be nice, if some well-maintained sample language (pl/sh or
> even pl/dummy) which serves as a sample of latest ways to make use of
> pl/function support in core pg code would be included in core as well.
And why do you think the above three don't serve that purpose? Or even
more to the point, how likely is it that an unused "dummy" language
would be well-maintained?
regards, tom lane
