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)
