Re: [HACKERS] removing tsearch2

[Mike Blackwell]

​There is also a mechanism for the results of the Perl module's "make test"
to be reported to a site which aggregates and reports them by Perl version
and OS - a sort of distributed build farm.  See for example
http://matrix.cpantesters.org/?dist=DBD-Pg+3.5.3

__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR Donnelley*
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
mike.blackw...@rrd.com
http://www.rrdonnelley.com



* *

On Mon, Feb 27, 2017 at 4:02 PM, David E. Wheeler 
wrote:

> On Feb 27, 2017, at 1:53 PM, Bruce Momjian  wrote:
>
> > Oh, does CPAN distribute compiled modules or requires users to compile
> > them.
>
> Like PGXN, it formally does not care, but its implementation expects
> source code distributions what will be built and installed by users. Note
> that the vast majority of those modules, -- even pure Perl modules -- are
> built with make.
>
> So users typically get their Perl modules in one of these ways:
>
> 1. As binaries from their distribution’s package manager. These tend to be
> updated manually by volunteers and not integrated into CPAN, though there
> are solutions such as [rpmcpan](https://github.com/iovation/rpmcpan) and
> [PPM](http://www.activestate.com/activeperl/ppm-perl-modules) which do
> regular distro package builds.
>
> 2. As source code from CPAN, from which they are compiled (when
> necessary), built, and installed by the user or a build system such as
> [Homebrew](https://brew.sh).
>
> Best,
>
> David
>
>

Re: [HACKERS] removing tsearch2

[David E. Wheeler]

On Feb 27, 2017, at 1:53 PM, Bruce Momjian  wrote:

> Oh, does CPAN distribute compiled modules or requires users to compile
> them.

Like PGXN, it formally does not care, but its implementation expects source 
code distributions what will be built and installed by users. Note that the 
vast majority of those modules, -- even pure Perl modules -- are built with 
make.

So users typically get their Perl modules in one of these ways:

1. As binaries from their distribution’s package manager. These tend to be 
updated manually by volunteers and not integrated into CPAN, though there are 
solutions such as [rpmcpan](https://github.com/iovation/rpmcpan) and 
[PPM](http://www.activestate.com/activeperl/ppm-perl-modules) which do regular 
distro package builds.

2. As source code from CPAN, from which they are compiled (when necessary), 
built, and installed by the user or a build system such as 
[Homebrew](https://brew.sh).

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [HACKERS] removing tsearch2

[Bruce Momjian]

On Mon, Feb 27, 2017 at 01:00:20PM -0800, David E. Wheeler wrote:
> On Feb 27, 2017, at 12:04 PM, Bruce Momjian  wrote:
> 
> > Just stating the obvious, but one of the reasons CPAN works so well is
> > that most of the modules are written in Perl and hence don't need
> > per-platform compilation.
> 
> There are a *lot* of C-baded modules on CPAN; and my guess is that, more 
> often than not, Perl modules depend on other C-based modules.
> 
> I daresay a lot of PostgreSQL extensions can be written in pure SQL or 
> PL/pgSQL.

Oh, does CPAN distribute compiled modules or requires users to compile
them.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +


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

Re: [HACKERS] removing tsearch2

[David E. Wheeler]

On Feb 27, 2017, at 12:04 PM, Bruce Momjian  wrote:

> Just stating the obvious, but one of the reasons CPAN works so well is
> that most of the modules are written in Perl and hence don't need
> per-platform compilation.

There are a *lot* of C-baded modules on CPAN; and my guess is that, more often 
than not, Perl modules depend on other C-based modules.

I daresay a lot of PostgreSQL extensions can be written in pure SQL or PL/pgSQL.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [HACKERS] removing tsearch2

[Bruce Momjian]

On Fri, Feb 17, 2017 at 09:54:37AM +0100, Magnus Hagander wrote:
> If we could somehow integrate PGXN with both the RPM build process, the DEB
> build process and a Windows build process (whether driven by PGXN or just "fed
> enough data" by PGXN is a different question), I think that would go a long 
> way
> towards the goal. Also being able to use this somehow to drive continuous
> builds and tests (kind of like a buildfarm-lite for a subset of platforms)
> would be useful for reaching a point where extensions outside of core can come
> at least close to what we deliver in core.

Just stating the obvious, but one of the reasons CPAN works so well is
that most of the modules are written in Perl and hence don't need
per-platform compilation.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +


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

Re: [HACKERS] removing tsearch2

[David E. Wheeler]

On Feb 17, 2017, at 12:54 AM, Magnus Hagander  wrote:

> If we could somehow integrate PGXN with both the RPM build process, the DEB 
> build process and a Windows build process (whether driven by PGXN or just 
> "fed enough data" by PGXN is a different question), I think that would go a 
> long way towards the goal.

My thought was that someone could rsync the PGXN repo every hour or something 
and build any new modules there. That’s how the search site is built: Every 
five minutes, it rsyncs rsync://master.pgxn.org/pgxn, parses the output to see 
new releases, and updates the index.

> Also being able to use this somehow to drive continuous builds and tests 
> (kind of like a buildfarm-lite for a subset of platforms) would be useful for 
> reaching a point where extensions outside of core can come at least close to 
> what we deliver in core.

Personally I just use Travis and Coveralls on GitHub for that sort of thing.

Best,

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [HACKERS] removing tsearch2

[Magnus Hagander]

On Tuesday, February 14, 2017, David E. Wheeler 
wrote:

> On Feb 14, 2017, at 9:37 AM, Magnus Hagander  > wrote:
>
> > It's a failing in one of the two at least. It either needs to be easier
> to build the things on windows, or pgxn would need to learn to do binary
> distributions.
>
> PGXN makes no effort to support installation on any platform at all. Happy
> to work with anyone who wants to add binary distribution, but supporting
> multiple platforms might be a PITA. Maybe there’d be a way to integrate
> with the RPM and .deb and Windows repos (is there something like that for
> Windows?).
>

Yeah, I think the core of the problem that nobody does that for platforms
ohter than RPM and DEB today (more or less). And the effort for those isn't
coordinated at that level, only for the main packages.

It may not be that PGXN is the entity that should be doing it, but if we
want to solve the problem than *someone* does. And until someone does, we
can't say "hey we have pgxn so extensions outside core are just as easy to
use as the ones in core".

WIndows does not have something quite to the level of DEB or RPM, but
there's definitely been some increase in the use of package managers
recently. I don't use or admin Windows anymore myself, but I've heard good
things about chocolatry for example. It might be worth investigating, if
somebody has the resources.

If we could somehow integrate PGXN with both the RPM build process, the DEB
build process and a Windows build process (whether driven by PGXN or just
"fed enough data" by PGXN is a different question), I think that would go a
long way towards the goal. Also being able to use this somehow to drive
continuous builds and tests (kind of like a buildfarm-lite for a subset of
platforms) would be useful for reaching a point where extensions outside of
core can come at least close to what we deliver in core.

//Magnus



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

Re: [HACKERS] removing tsearch2

[David E. Wheeler]

On Feb 14, 2017, at 9:37 AM, Magnus Hagander  wrote:

> It's a failing in one of the two at least. It either needs to be easier to 
> build the things on windows, or pgxn would need to learn to do binary 
> distributions. 

PGXN makes no effort to support installation on any platform at all. Happy to 
work with anyone who wants to add binary distribution, but supporting multiple 
platforms might be a PITA. Maybe there’d be a way to integrate with the RPM and 
.deb and Windows repos (is there something like that for Windows?).

> Even if we get the building easier on windows, it'll likely remain a second 
> class citizen (though better than today's third class), given the amount of 
> windows machines that actually have a compiler on them for start. Pgxs in 
> Windows would be a big improvement, but it won't solve the problem. 

Yep.

David



smime.p7s
Description: S/MIME cryptographic signature

Re: [HACKERS] removing tsearch2

[Magnus Hagander]

On Feb 14, 2017 18:26, "David E. Wheeler"  wrote:

On Feb 14, 2017, at 5:37 AM, Jim Nasby  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.



It's a failing in one of the two at least. It either needs to be easier to
build the things on windows, or pgxn would need to learn to do binary
distributions.

Even if we get the building easier on windows, it'll likely remain a second
class citizen (though better than today's third class), given the amount of
windows machines that actually have a compiler on them for start. Pgxs in
Windows would be a big improvement, but it won't solve the problem.

/Magnus

Re: [HACKERS] removing tsearch2

[David E. Wheeler]

On Feb 14, 2017, at 5:37 AM, Jim Nasby  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



smime.p7s
Description: S/MIME cryptographic signature

Re: [HACKERS] removing tsearch2

[Robert Haas]

On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby  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

Re: [HACKERS] removing tsearch2

[Jim Nasby]

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

Re: [HACKERS] removing tsearch2

[Robert Haas]

On Fri, Feb 10, 2017 at 1:41 PM, Robert Haas  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

Re: [HACKERS] removing tsearch2

[Magnus Hagander]

On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby  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/

Re: [HACKERS] removing tsearch2

[Jim Nasby]

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

Re: [HACKERS] removing tsearch2

[Andrew Dunstan]

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  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 Dunstanhttps://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

Re: [HACKERS] removing tsearch2

[Robert Haas]

On Fri, Feb 10, 2017 at 12:32 PM, Tom Lane  wrote:
> Robert Haas  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

Re: [HACKERS] removing tsearch2

[Josh Berkus]

On 02/10/2017 10:18 AM, Peter Geoghegan wrote:
> On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas  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

Re: [HACKERS] removing tsearch2

[Robert Haas]

On Fri, Feb 10, 2017 at 1:18 PM, Peter Geoghegan  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

Re: [HACKERS] removing tsearch2

[Peter Geoghegan]

On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas  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

Re: [HACKERS] removing tsearch2

[Josh Berkus]

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  wrote:
>>> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
 * Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  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

Re: [HACKERS] removing tsearch2

[Tom Lane]

Robert Haas  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

Re: [HACKERS] removing tsearch2

[Robert Haas]

On Fri, Feb 10, 2017 at 9:28 AM, Tom Lane  wrote:
> Robert Haas  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

Re: [HACKERS] removing tsearch2

[David Steele]

On 2/10/17 6:28 AM, Robert Haas wrote:
> On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund  wrote:
>> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
>>> * Robert Haas (robertmh...@gmail.com) wrote:
 On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  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
da...@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

Re: [HACKERS] removing tsearch2

[Alexander Korotkov]

On Fri, Feb 10, 2017 at 2:28 PM, Robert Haas  wrote:

> On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund  wrote:
> > On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
> >> * Robert Haas (robertmh...@gmail.com) wrote:
> >> > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  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

Re: [HACKERS] removing tsearch2

[Tom Lane]

Robert Haas  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

Re: [HACKERS] removing tsearch2

[Daniel Gustafsson]

> On 10 Feb 2017, at 12:28, Robert Haas  wrote:
> 
> On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund  wrote:
>> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
>>> * Robert Haas (robertmh...@gmail.com) wrote:
 On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  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

Re: [HACKERS] removing tsearch2

[Michael Paquier]

On Fri, Feb 10, 2017 at 8:28 PM, Robert Haas  wrote:
> On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund  wrote:
>> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
>>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  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

[HACKERS] removing tsearch2

[Robert Haas]

On Thu, Feb 9, 2017 at 7:37 PM, Andres Freund  wrote:
> On 2017-02-09 19:19:21 -0500, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>> > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane  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.

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