removing tsearch2

On Fri, Feb 10, 2017 at 8:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund <andres@anarazel.de> wrote:

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, our experience with contrib/tsearch2 suggests that the extension
shouldn't be part of contrib, because we have zero track record of getting
rid of stuff in contrib, no matter how dead it is.

Let's nuke tsearch2 to remove this adverse precedent, and then add the
new thing.

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

+1.
-- 
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10 Feb 2017, at 12:28, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund <andres@anarazel.de> wrote:

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, our experience with contrib/tsearch2 suggests that the extension
shouldn't be part of contrib, because we have zero track record of getting
rid of stuff in contrib, no matter how dead it is.

Let's nuke tsearch2 to remove this adverse precedent, and then add the
new thing.

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

FWIW, +1

cheers ./daniel

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

I'm abstaining on the actual vote, but I just wanted to note that there's
at least two layers of stub compatibility functions in core that are
there only to support tsearch2, cf commits
eb43e851d6b3fa0c4516efcfdf29a183f7717a43
6595dd04d136d5c97ae05fc580572c8f00042143
... and there might be more that I missed in quickly scanning the
commit log. We should probably investigate whether those can be
gotten rid of without damaging the maintainability of the external
module. I *think* these were only needed as short-term hacks but
don't want to say for sure because ENOCAFFEINE.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Feb 10, 2017 at 2:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund <andres@anarazel.de> wrote:

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, our experience with contrib/tsearch2 suggests that the

extension

shouldn't be part of contrib, because we have zero track record of

getting

rid of stuff in contrib, no matter how dead it is.

Let's nuke tsearch2 to remove this adverse precedent, and then add the
new thing.

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

+1

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On 2/10/17 6:28 AM, Robert Haas wrote:

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund <andres@anarazel.de> wrote:

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, our experience with contrib/tsearch2 suggests that the extension
shouldn't be part of contrib, because we have zero track record of getting
rid of stuff in contrib, no matter how dead it is.

Let's nuke tsearch2 to remove this adverse precedent, and then add the
new thing.

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

+1

--
-David
david@pgmasters.net

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Feb 10, 2017 at 9:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

I'm abstaining on the actual vote, but I just wanted to note that there's
at least two layers of stub compatibility functions in core that are
there only to support tsearch2, cf commits
eb43e851d6b3fa0c4516efcfdf29a183f7717a43
6595dd04d136d5c97ae05fc580572c8f00042143
... and there might be more that I missed in quickly scanning the
commit log. We should probably investigate whether those can be
gotten rid of without damaging the maintainability of the external
module. I *think* these were only needed as short-term hacks but
don't want to say for sure because ENOCAFFEINE.

That's not a bad idea, but I think it's an independent issue. If the
hacks are still needed for an external module, we shouldn't go out of
our way to remove them even if we nuke tsearch2 (but we don't need to
maintain them going forward unless we get a complaint). If they hacks
aren't still needed, they could be removed whether or not we keep
tsearch2 in contrib. Unless I'm confused?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

That's not a bad idea, but I think it's an independent issue. If the
hacks are still needed for an external module, we shouldn't go out of
our way to remove them even if we nuke tsearch2 (but we don't need to
maintain them going forward unless we get a complaint). If they hacks
aren't still needed, they could be removed whether or not we keep
tsearch2 in contrib. Unless I'm confused?

Technically, it's probably independent of whether we keep tsearch2 in
contrib. I think (but haven't researched it) that it's more a matter
of whether we care to still support direct upgrades from pre-release-N
versions of tsearch2, for some N. Politically though, I think it'll
be easier to make an aggressive decision in that regard if we are
tossing tsearch2 out of contrib.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 02/10/2017 06:41 AM, David Steele wrote:

On 2/10/17 6:28 AM, Robert Haas wrote:

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund <andres@anarazel.de> wrote:

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, our experience with contrib/tsearch2 suggests that the extension
shouldn't be part of contrib, because we have zero track record of getting
rid of stuff in contrib, no matter how dead it is.

Let's nuke tsearch2 to remove this adverse precedent, and then add the
new thing.

Anybody who still wants tsearch2 can go get it from an old version, or
somebody can maintain a fork on github.

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere). Starting a new
thread to make sure we collect all the relevant votes, but I really,
really think it's past time for this to go away. The last actual
change to tsearch2 which wasn't part of a wider cleanup was
3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
7 years since there's been any real work done on this -- and the
release where we brought tsearch into core is now EOL, plus three more
releases besides.

+1

+1

--
Josh Berkus
Containers & Databases Oh My!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere).

+1.

I'd also be in favor of either removing contrib/isn, or changing it so
that the ISBN country code prefix enforcement went away. That would
actually not imply and real loss of functionality from a practical
perspective, since you can still enforce that the check digit is
correct without any of that. I think that the existing design of some
parts of contrib/isn is just horrible.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Feb 10, 2017 at 1:18 PM, Peter Geoghegan <pg@bowt.ie> wrote:

I'd also be in favor of either removing contrib/isn, or changing it so
that the ISBN country code prefix enforcement went away. That would
actually not imply and real loss of functionality from a practical
perspective, since you can still enforce that the check digit is
correct without any of that. I think that the existing design of some
parts of contrib/isn is just horrible.

There's no question that contrib/isn is not well-designed, but whether
to remove it is a question for a different thread than this one.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 02/10/2017 10:18 AM, Peter Geoghegan wrote:

On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere).

+1.

I'd also be in favor of either removing contrib/isn, or changing it so
that the ISBN country code prefix enforcement went away. That would
actually not imply and real loss of functionality from a practical
perspective, since you can still enforce that the check digit is
correct without any of that. I think that the existing design of some
parts of contrib/isn is just horrible.

+1 to quick-fix it, -1 to just delete it.

There's a bunch of these things in /contrib which really ought to be
PGXN extensions (also CUBE, earthdistance, etc.). However, one of the
steps in that would be getting the mainstream platforms to package them
so that users have a reasonable upgrade path, so I would not propose
doing it for 10.

--
Josh Berkus
Containers & Databases Oh My!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Feb 10, 2017 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

That's not a bad idea, but I think it's an independent issue. If the
hacks are still needed for an external module, we shouldn't go out of
our way to remove them even if we nuke tsearch2 (but we don't need to
maintain them going forward unless we get a complaint). If they hacks
aren't still needed, they could be removed whether or not we keep
tsearch2 in contrib. Unless I'm confused?

Technically, it's probably independent of whether we keep tsearch2 in
contrib. I think (but haven't researched it) that it's more a matter
of whether we care to still support direct upgrades from pre-release-N
versions of tsearch2, for some N. Politically though, I think it'll
be easier to make an aggressive decision in that regard if we are
tossing tsearch2 out of contrib.

I agree that it's OK to desupport direct upgrades from ancient
releases to the very latest code at some point in time, and if
somebody thinks that's important work to reduce future maintenance or
just to tidy up, I'm not going to oppose it strenuously. But I
wouldn't be in any rush either.

Anyway, it seems like the consensus here is unanimous. Unless there
are a LARGE number of contrary votes in the meanwhile, I'll go make
this happen sometime next week.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 02/10/2017 01:27 PM, Josh Berkus wrote:

On 02/10/2017 10:18 AM, Peter Geoghegan wrote:

On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Works for me.

+1

OK, that's three votes in favor of removing tsearch2 (from core,
anyone who wants it can maintain a copy elsewhere).

+1.

I'd also be in favor of either removing contrib/isn, or changing it so
that the ISBN country code prefix enforcement went away. That would
actually not imply and real loss of functionality from a practical
perspective, since you can still enforce that the check digit is
correct without any of that. I think that the existing design of some
parts of contrib/isn is just horrible.

+1 to quick-fix it, -1 to just delete it.

There's a bunch of these things in /contrib which really ought to be
PGXN extensions (also CUBE, earthdistance, etc.). However, one of the
steps in that would be getting the mainstream platforms to package them
so that users have a reasonable upgrade path, so I would not propose
doing it for 10.

Part of the reason for keeping a number of extensions is that it helps
test our extension infrastructure. Also they server as good pieces of
example code. So I don't want to get rid of them all, or even any of
them that have any degree of significant use. I think these days
tsearch2 is very largely redundant, so that means there's a good reason
not to keep it. But that's not true of cube, isn etc.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2/10/17 2:24 PM, Andrew Dunstan wrote:

There's a bunch of these things in /contrib which really ought to be
PGXN extensions (also CUBE, earthdistance, etc.). However, one of the
steps in that would be getting the mainstream platforms to package them
so that users have a reasonable upgrade path, so I would not propose
doing it for 10.

Part of the reason for keeping a number of extensions is that it helps
test our extension infrastructure. Also they server as good pieces of
example code. So I don't want to get rid of them all, or even any of
them that have any degree of significant use. I think these days
tsearch2 is very largely redundant, so that means there's a good reason
not to keep it. But that's not true of cube, isn etc.

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.
--
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

On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:

On 2/10/17 2:24 PM, Andrew Dunstan wrote:

There's a bunch of these things in /contrib which really ought to be

PGXN extensions (also CUBE, earthdistance, etc.). However, one of the
steps in that would be getting the mainstream platforms to package them
so that users have a reasonable upgrade path, so I would not propose
doing it for 10.

Part of the reason for keeping a number of extensions is that it helps
test our extension infrastructure. Also they server as good pieces of
example code. So I don't want to get rid of them all, or even any of
them that have any degree of significant use. I think these days
tsearch2 is very largely redundant, so that means there's a good reason
not to keep it. But that's not true of cube, isn etc.

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".

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).

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Fri, Feb 10, 2017 at 1:41 PM, Robert Haas <robertmhaas@gmail.com> wrote:

Anyway, it seems like the consensus here is unanimous. Unless there
are a LARGE number of contrary votes in the meanwhile, I'll go make
this happen sometime next week.

Done.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:

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.

I'm not sure a need-based test is going to be entirely the right
thing. The advantage of having something in contrib is that the core
developers will maintain it for you. When things change from release
to release, everything in contrib necessarily gets updated; things on
PGXN or elsewhere only get updated if their owners update them. There
are several good things about that. First, it means that people can
rely on the stuff in contrib mostly sticking around for future
releases, except occasionally when we decide to drop a module.
Second, it gives maintainers of external modules examples of what they
need to do to update their code when we change the core APIs. Third,
it's probably actually more efficient for one person to go sweep
through a large number of modules and fix them all at once than if
those things were all on PGXN with separate owners. Now, you can
overdo that: I don't want to be responsible for every module on PGXN
or anything close to it. But on balance I think there's a good case
for shipping a substantial set of modules in contrib.

I think, in general, that we've done a good job increasing the quality
of contrib over time. Pretty much all of the new stuff we've added is
fairly solid, and we cleaned things up significantly by moving test
code to src/test/modules. But we've still got some older modules in
contrib whose quality and general usefulness is pretty questionable
IMV: earthdistance, intagg, intarray, isn, and of course the
eternally-deprecated but never-actually-removed xml2. I'm not in a
hurry to expend a lot of energy removing any of that stuff, and I
think we might be reaching our quota of backward-incompatible changes
for this release, but it's questionable in my mind whether having
those things there works out to a net plus. There's a lot of good
stuff in contrib, though, and I don't think we should be averse to
adding more in the future. It shouldn't be just that any random
contrib module somebody writes can get dropped into the core
distribution, but I think we ought to be open to reasonable proposals
to add things there when it makes sense.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Feb 14, 2017, at 5:37 AM, Jim Nasby <Jim.Nasby@BlueTreble.com> wrote:

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.

Yeah, that’s outside of PGXN’s mandate. It doesn’t do any installing at all, just distribution (release, search, download). Even the Python client just looks to see what build support is in a distribution it downloads to decide how to build it (make, configure, etc.), IIRC.

David