cowwoc wrote > On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote: >> On 09/15/2014 11:49 AM, cowwoc wrote: >>> I think developers choosing this route (myself included) are willing >>> to pay the price in exchange for improved readability/maintainability >>> (the assumption being that the resulting performance will be "good >>> enough"). There seem to be plenty of people heading in this direction >>> otherwise other languages (like pl/v8) wouldn't enjoy the popularity >>> they do. >>> >>> Gili >> I've seen too many good java developers write too much terrible >> database-oriented code. If they are good with db and sql, plpgsql >> will not be a problem to learn. > > lup, > > Then does Postgresql support languages other than pl/pgsql? I'm not > trying to tear down pl/pgsql, simply pointing out that there is strong > demand for other languages as well. > > And to answer Pavel's earlier point: the lack of developers getting > behind pl/java and JDBC driver does not equate the lack of demand for > those tools. For every one person contributing patches, there are 1000s > who do not but are more than happy to use the finished work. > > Gili I'm singing with the choir here but getting some of those thousand bodies contributing to both pl/java and existing or "next generation" Jdbc drivers would be nice. And that doesn't just mean code - updated articles and buildfarm animals are just a couple of resources that could be contributed. If nothing else make the projects look more lively than current even if the code itself is unchanged. If you know SQL and Java then you have enough skill and experience to use the proper tool for the job instead of turning everything in a java-nail for your java-hammer. Most everything that can be done in this arena can be done outside of core. There may be things a pure java developer would like the core to provide that would require C programming skills but likely, as mentioned, those support parts would benefit more than only Java and would be embraced by the core community. I'll agree, though without personal experience, that a java trigger is more portable than a pl/pgsql one. At the same time users utilizing PostgreSQL to its fullest are going to have significant portability issues since custom data types and aggregates, arrays, and other advanced features that are used by applications are not all that portable. I think we'd love to help make it easier for java-only shops to target PostgreSQL as their backend but there has to be some payoff to the people putting up the resources to make it happen. That is much more likely to occur because someone with a huge installed base of java code wants to use PostgreSQL to enhance their product. In that case adding more core features to entice those people to come over seems a better approach than devoting resources to adding capabilities that may not be strongly accepted nor fully useful because the people writing them are not sufficiently invested in the outcome. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819145.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
