mark@mark.mielke.cc writes:
> This is why I was thinking that the problem is that the backend (SPI?)
> API isn't exposed as native methods in the required languages. If just
> the SPI API was exposed from the core to the languages, the
> maintenance effort and size should be less, and the add-ons would not
> require that they be built with the PostgreSQL core, making it easy to
> integrate them after the fact.
It's not just SPI --- SPI for instance doesn't deal at all with the
problem of how you create a language call handler function. SPI was
never intended to be a "complete" API, but rather something easy to
use that covers most cases of C code needing to invoke SQL queries.
Code that's trying to offer features to SQL is entirely orthogonal
to what SPI is about.
I'm not real sure what a feature-complete API for language handlers
might look like, but it'd cover far more than SPI does. And this
really just begs the question: could we afford to promise a frozen
API that *is* feature-complete at that level? The changes we've made
recently that affected both core and PLs have mostly been things like
adding OUT parameter support, which certainly would have involved
changing a language handler API; or modifications to the system
catalogs, which I can't see a handler API masking; or changes to the
conventions for passing tuples as Datums, which again I doubt an API
would have successfully hidden.
It's an interesting idea to think about, but I think any solution
of this kind is a long way off, unless the internals of the backend
suddenly become a lot more stable than they have been in the past.
regards, tom lane
