A broad question - would it make sense to add links to non-C extensions in the FAQ or blog? It would allow many more people to write extensions as long as they don't have fancy needs. Even they have really hairy requirements it might make sense to use a combination of a C extension for the parts that have to be written in C and a language more familiar to the developer (or which has the required libraries, etc.) for the rest.
The main "con" is that it's not as powerful as a C extension. E.g., the author has some support for FDW but in general you'll still need to use C (or one of the other p/* extensions) if you want an FDW.
The main "pro" is that it removes the need to know anything about the PostgreSQL server internals. No special macros, no special tools to prepare artifacts for inclusion. For many applications you don't even need to know that you're running within a database server instead of a client.
I think the benefit of this can't be overstated. Far fewer people know C now, and the types of problems that need to be solved are likely to be written in specialized languages. (R anyone?)
There's not going to be a lot of developers comfortable writing a database server extension in C and writing non-trivial accessing R libraries via a C binding - If they even exist.
There are some drawbacks. E.g., java doesn't have the performance issues it had years ago but since it uses a different memory model than C you might have a performance hit just from the data conversion as it goes through the C-to-java adapter. However I suspect many UDFs and UDTs implemented in the PL/* languages would have acceptable performance given the much lower effort required to implement the extension. At least for compiled languages like java and python.
....
I guess the "ask" is just whether the FAQ should point to a page that covers these points. PGNX is focused on C extensions but you can write extensions in any supported language. That may be a better solution for many people while C extensions focus on the highest performance and newest features.
Then a list of resources, e.g., for java go to the link above, etc., since they can be hard to find.
....
I have an example project here:
https://github.com/beargiles/pljava-udt-type-extension. It's a generic name since I only used it when writing a series of articles on pl/java for my blog (starting here:
https://invariantproperties.com/?p=549) - I couldn't imagine the world beating down my door for yet another implementation of a "rational" or "complex" UDT but it
would be helpful to be able to compare implementations in C and java to see what's identical and what's different.
It's everything a UDT would want:
- related UDF
- overloaded operators (+, -, etc)
- hashes
- ordering (only rational)
- indexes (rational: btree + hash, complex: only hash)
plus a non-trivial example of an "OMG why didn't somebody tell me about this sooner" java DDR.
This is pretty old - I'll probably flesh out a few ideas I had years ago but never implemented as additional examples.
Bear