On 2/13/17 2:37 AM, Magnus Hagander wrote:
That's based on an assumption that PGXN shouldn't be treated as part of the community effort, which I think is a mistake. Having a robust, community run extension/package/module framework has proven to be extremely valuable for other programming environments, and IMHO we should be striving to improve in that area.Until pgxn has a way of helping users on for example Windows (or other platforms where they don't have a pgxs system and a compiler around), it's always going to be a "second class citizen".
I view that as more of a failing of pgxs than pgxn. Granted, the most common (only?) pgxn client right now is written in python, but it's certainly possible to run that on windows with some effort (BigSQL does it), and I'm fairly certain it's not that hard to package a python script as a windows .exe.
It's certainly part of the community efforts in many ways, but it's a significant loss of usability compared to things that are included. And from the perspective of the testing the infrastructure, you'd loose a lot of platform coverage (unless you can find a way to integrate pgxn building with the buildfarm).
Right; I think we need at least some amount of pgxn buildfarm coverage. There probably also needs to be a way to officially bless certain distributions. Unless there's a pretty significant need for an official extension to be in contrib, it should go into PGXN.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
