Andrew Dunstan wrote:
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.
I concur with this. The needs for a module like PL/Java is very different then the needs of
PL/Perl so let's get some more PL's in before we do a refactoring effort to create common
API's. Personally, I'm not sure what would be included. The call handler API's together with
the SPI API's are in essence what you need. The rest is fairly specialized anyway.
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.
This is partly why I'd like to get PL/Java included. Not that I expect any of them to devote
resources to PL/Java but I think that they, from time to time, will visit the code. If not
for anything else then to see why some other change caused build failures. It's always
easier to have discussions around code that you know they all have on disk.
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.
As the project grows for various reasons, the number of hackers in the community will grow
as well. PL/Java for instance, does not come without resources :-)
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
