Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Jeff Janes
On Fri, Jun 5, 2015 at 7:42 AM, Joshua D. Drake wrote: > > On 06/05/2015 04:56 AM, Robert Haas wrote: > somewhere else. At least not that I can see. > >> >> 4. Eliminate the EGO of saying "I have a contrib module in core" >>> >> >> I've got multiple major features in core. Any ego I may have a

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread David E. Wheeler
On Jun 5, 2015, at 10:47 AM, Jim Nasby wrote: >> Right. Just stick it in your README. >> >> http://blog.pgxn.org/post/116087351668/badges > > I meant something more integrated with PGXN itself, such as what you're > proposing for pgxn-tester. That would allow for things like PGXN search > r

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Jim Nasby
On 6/5/15 10:49 AM, David E. Wheeler wrote: On Jun 5, 2015, at 12:34 AM, Jim Nasby wrote: A number of modules also run Travis-CI. Might be worth having a way for a module to provide it's status .png. Right. Just stick it in your README. http://blog.pgxn.org/post/116087351668/badges I

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Alvaro Herrera
Andrew Dunstan wrote: > It's also quite possible to test extensions in the buildfarm using an addon > module, which is mostly boilerplate. Of course, that does require that > you're running a buildfarm member. Here's the code for the module that tests > the FileTextArray extension. >

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread David E. Wheeler
On Jun 5, 2015, at 12:34 AM, Jim Nasby wrote: > A number of modules also run Travis-CI. Might be worth having a way for a > module to provide it's status .png. Right. Just stick it in your README. http://blog.pgxn.org/post/116087351668/badges David smime.p7s Description: S/MIME cryptogra

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Neil Tiffin
> On Jun 4, 2015, at 3:11 PM, David E. Wheeler wrote: > > On Jun 4, 2015, at 11:53 AM, Neil Tiffin wrote: > >> I have looked at PGXN and would never install anything from it. Why? >> Because it is impossible to tell, without inside knowledge or a lot of work, >> what is actively maintained

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread David Fetter
On Thu, Jun 04, 2015 at 01:11:21PM -0700, David E. Wheeler wrote: > On Jun 4, 2015, at 11:53 AM, Neil Tiffin wrote: > > > I have looked at PGXN and would never install anything from it. > > Why? Because it is impossible to tell, without inside knowledge > > or a lot of work, what is actively mai

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Bruce Momjian
On Fri, Jun 5, 2015 at 02:42:45PM +0100, Simon Riggs wrote: > On 29 May 2015 at 02:50, Peter Eisentraut wrote: > > On 5/28/15 3:35 PM, Stephen Frost wrote: > > What we would need for this is an 'extensions' directory, or similar, > > and a clear definition of what the requirements ar

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Andrew Dunstan
On 06/05/2015 03:34 AM, Jim Nasby wrote: On 6/4/15 3:11 PM, David E. Wheeler wrote: There is no indication of what versions of pg any of PGXN modules are tested on, or even if there are tests that can be run to prove the module works correctly with a particular version of pg. Yeah, I’ve been m

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Joshua D. Drake
On 06/05/2015 04:56 AM, Robert Haas wrote: somewhere else. At least not that I can see. 4. Eliminate the EGO of saying "I have a contrib module in core" I've got multiple major features in core. Any ego I may have about my PostgreSQL contributions is not based on pg_prewarm. This was wor

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Robert Haas
On Fri, Jun 5, 2015 at 8:32 AM, Stephen Frost wrote: > Painting it as the unilateral actions of one committer is uncharitable, > at best. As I see it, it is just stating the facts. There were several emails from other committers on the pg_audit thread not that long before it was committed, and z

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Simon Riggs
On 29 May 2015 at 02:50, Peter Eisentraut wrote: > On 5/28/15 3:35 PM, Stephen Frost wrote: > > What we would need for this is an 'extensions' directory, or similar, > > and a clear definition of what the requirements are around getting into > > it are. With that, we could decide for each module

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Jun 4, 2015 at 2:33 PM, Joshua D. Drake > wrote: > > 1. 15 years of the same argument (current source: pg_audit) > > The argument about pg_audit has little to do with contrib. It is > primarily about code quality, and secondarily a

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Robert Haas
On Thu, Jun 4, 2015 at 2:33 PM, Joshua D. Drake wrote: > My argument was (after some preliminary discussion): > > 1. Review contrib > 2. All modules that are "core worthy" install by default > 3. Push all other contrib out into the wild So above, I said that we keep adding to contrib because "the

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-05 Thread Jim Nasby
On 6/4/15 3:11 PM, David E. Wheeler wrote: There is no indication of what versions of pg any of PGXN modules are tested on, or even if there are tests that can be run to prove the module works correctly with a particular version of pg. Yeah, I’ve been meaning to integratehttp://pgxn-tester.org

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread David E. Wheeler
On Jun 4, 2015, at 11:53 AM, Neil Tiffin wrote: > I have looked at PGXN and would never install anything from it. Why? > Because it is impossible to tell, without inside knowledge or a lot of work, > what is actively maintained and tested, and what is an abandoned > proof-of-concept or idea.

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Neil Tiffin
> On Jun 4, 2015, at 10:55 AM, Jim Nasby wrote: > > Personally, I'd rather we publish a list of formally vetted and approved > versions of PGXN modules. There are many benefits to that, and the downside > of not having that stuff as part of make check would be overcome by the > explicit testi

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Andres Freund
On 2015-06-04 20:41:46 +0200, Andres Freund wrote: > > 1. 15 years of the same argument (current source: pg_audit) > > I don't see getting rid of contrib helping with that. The only change > will then be whether something should be in core. > > And there's stuff that's just very hard to develop o

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Andres Freund
On 2015-06-04 11:33:47 -0700, Joshua D. Drake wrote: > My argument was (after some preliminary discussion): > > 1. Review contrib > 2. All modules that are "core worthy" install by default > 3. Push all other contrib out into the wild > > Possibly: > > 1. Have a contrib project that sat outside

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Joshua D. Drake
On 06/04/2015 11:01 AM, Robert Haas wrote: On Thu, Jun 4, 2015 at 1:57 PM, Joshua D. Drake wrote: I think it's because there are some things we want to include in the core distribution without baking them irrevocably into the server. I have mentioned before isn't really what this discussion

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Robert Haas
On Thu, Jun 4, 2015 at 1:57 PM, Joshua D. Drake wrote: >> I think it's because there are some things we want to include in the >> core distribution without baking them irrevocably into the server. > > I have mentioned before isn't really what this discussion is about. Stephen > Frost and I even we

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Joshua D. Drake
On 06/04/2015 10:34 AM, Robert Haas wrote: On Thu, Jun 4, 2015 at 11:49 AM, Joshua D. Drake wrote: Except, that is kind of the point. Why are we adding to it? If you don't know the answer to that question already, then you probably shouldn't be proposing to get rid of the thing. I know t

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Robert Haas
On Thu, Jun 4, 2015 at 11:49 AM, Joshua D. Drake wrote: > Except, that is kind of the point. Why are we adding to it? If you don't know the answer to that question already, then you probably shouldn't be proposing to get rid of the thing. I think it's because there are some things we want to inc

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Joshua D. Drake
On 06/04/2015 08:55 AM, Jim Nasby wrote: Personally, I'd rather we publish a list of formally vetted and approved versions of PGXN modules. There are many benefits to that, and the downside of not having that stuff as part of make check would be overcome by the explicit testing we would need to

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Joshua D. Drake
On 06/04/2015 09:00 AM, Andrew Dunstan wrote: No. You keep getting this wrong. The fact that we have extensions doesn't mean that we want to throw out everything that is an extension. It's perfectly reasonable for us to maintain some ourselves, not least as part of eating out own dog food. Y

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Andrew Dunstan
On 06/04/2015 11:49 AM, Joshua D. Drake wrote: On 06/04/2015 07:34 AM, Robert Haas wrote: I don't think it's very practical to talk about getting rid of contrib when we reliably add to it in every release: Except, that is kind of the point. Why are we adding to it? Contrib (AFAICS) is all

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Tom Lane
Robert Haas writes: > On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan wrote: >> The biggest problem is that packagers tend just to bundle contrib together >> in one lump. If we could divide it into two, something like "standard >> modules" and "misc", with the former being included with the serve

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Jim Nasby
On 6/4/15 10:30 AM, Robert Haas wrote: On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan wrote: >The biggest problem is that packagers tend just to bundle contrib together >in one lump. If we could divide it into two, something like "standard >modules" and "misc", with the former being included w

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Joshua D. Drake
On 06/04/2015 07:34 AM, Robert Haas wrote: I don't think it's very practical to talk about getting rid of contrib when we reliably add to it in every release: Except, that is kind of the point. Why are we adding to it? Contrib (AFAICS) is all things that don't need to be in -core. That is th

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Robert Haas
On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan wrote: > The biggest problem is that packagers tend just to bundle contrib together > in one lump. If we could divide it into two, something like "standard > modules" and "misc", with the former being included with the server package, > I think that

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Andrew Dunstan
On 06/04/2015 10:34 AM, Robert Haas wrote: For what it's worth, I also don't particularly support renaming contrib. I don't really see that it buys us enough to justify the hassle it will cause. One thing that may be worth doing yet is separating the code that is just intended as a POC (lik

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-04 Thread Robert Haas
On Fri, May 29, 2015 at 10:30 AM, Stephen Frost wrote: > That work will be much less if we simply split what's in contrib now > into extension and contrib directories, as it's still all one source > repo to the packagers. If we punt things out (unless they're being > formally deprecated/removed)

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-02 Thread David Fetter
On Mon, Jun 01, 2015 at 05:48:16PM -0300, Alvaro Herrera wrote: > Peter Eisentraut wrote: > > > But it is a valid point that we'd need to build up more extension > > API tests before we start cutting back significantly on the > > maybe-example-maybe-real extensions that we ship in contrib. We > >

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-01 Thread Alvaro Herrera
Peter Eisentraut wrote: > But it is a valid point that we'd need to build up more extension API > tests before we start cutting back significantly on the > maybe-example-maybe-real extensions that we ship in contrib. We need to > find a good middle ground. Nowadays we can test concurrent behavio

Re: [HACKERS] RFC: Remove contrib entirely

2015-06-01 Thread Peter Eisentraut
On 5/29/15 5:35 PM, Tom Lane wrote: > But let's get to the point: the real reason for keeping most of these > contrib modules in the core distribution is that they are essential test > cases for core's extensibility features. contrib/isn is actually a good > example of that. It made us realize th

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Josh Berkus
On 05/29/2015 02:54 PM, Tom Lane wrote: > Peter Geoghegan writes: >> The problem here is that these ranges are controlled by a >> decentralized patchwork of national standards bodies, and the ranges >> are always subject to revision. I think that it's egregious that >> contrib/isn imagines it can

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Peter Geoghegan
On Fri, May 29, 2015 at 2:54 PM, Tom Lane wrote: > Well, that module has already been rewritten once (which proves that > there's an audience out there for it). Perhaps somebody will rewrite it > again to support a non-hardwired set of ranges. Now that we have the > concept of an extension confi

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Tom Lane
Peter Geoghegan writes: > The problem here is that these ranges are controlled by a > decentralized patchwork of national standards bodies, and the ranges > are always subject to revision. I think that it's egregious that > contrib/isn imagines it can track that with a static array. Well, that mo

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Peter Geoghegan
On Fri, May 29, 2015 at 2:35 PM, Tom Lane wrote: > It made us realize that extensions that create types > that are physically equivalent to int8 or float8 were broken when we made > those types potentially pass-by-value; we had to add a CREATE TYPE option > to allow that to still work (cf commit 3

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Tom Lane
Josh Berkus writes: > On 05/29/2015 02:08 PM, Peter Geoghegan wrote: >> I always liked the idea of organizing contrib along these lines. >> >> I know that I will never be successful in convincing people to remove, >> say, contrib/isn, which is total garbage, but the next best thing is >> to categ

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Peter Geoghegan
On Fri, May 29, 2015 at 11:47 AM, Josh Berkus wrote: > A. Extra commands and tools which aren't considered general enough, or > reliable enough, to be included by default, e.g. pg_standby, pgbench and > vacuumlo. > > B. Developer tools, like spi, start-scripts, and oid2name. > > C. "Core Extension

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Josh Berkus
On 05/29/2015 02:08 PM, Peter Geoghegan wrote: > On Fri, May 29, 2015 at 11:47 AM, Josh Berkus wrote: >> A. Extra commands and tools which aren't considered general enough, or >> reliable enough, to be included by default, e.g. pg_standby, pgbench and >> vacuumlo. >> >> B. Developer tools, like sp

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 21:59 GMT+02:00 Joshua D. Drake : > > On 05/29/2015 12:30 PM, Pavel Stehule wrote: > > Contrib made sense years ago. It does not any longer. Let's put the >> old horse down and raise a new herd of ponies on a new pasture. >> >> >> Still there is strong sense - it is a referenti

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Joshua D. Drake
On 05/29/2015 12:30 PM, Pavel Stehule wrote: Contrib made sense years ago. It does not any longer. Let's put the old horse down and raise a new herd of ponies on a new pasture. Still there is strong sense - it is a referential implementation of our extension API. We need it to find re

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 21:20 GMT+02:00 Joshua D. Drake : > > On 05/29/2015 11:27 AM, Jeff Janes wrote: > > It would be less confusing for users. Contrib modules seem to be >> first class extensions, leaving doubt on other extensions. >> >> >> Presumably there are still going to be some extensions mai

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Joshua D. Drake
On 05/29/2015 11:27 AM, Jeff Janes wrote: It would be less confusing for users. Contrib modules seem to be first class extensions, leaving doubt on other extensions. Presumably there are still going to be some extensions maintained by -hackers, and some not. I don't think we are goin

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Joshua D. Drake
On 05/29/2015 11:02 AM, Jeff Janes wrote: Also, removing a feature is a regression, and someone is always bound to complain... What is the real benefit? ISTM that it is a solution that fixes no important problem. Reaching a consensus about what to move here or there will consum

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Josh Berkus
All, So there are currently three kinds of things in contrib: A. Extra commands and tools which aren't considered general enough, or reliable enough, to be included by default, e.g. pg_standby, pgbench and vacuumlo. B. Developer tools, like spi, start-scripts, and oid2name. C. "Core Extensions"

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Jeff Janes
On Thu, May 28, 2015 at 11:26 PM, Guillaume Lelarge wrote: > Le 29 mai 2015 8:01 AM, "Fabien COELHO" a écrit : > > > > > >> FWIW, I don't mind which one we put in core and which one we put out of > >> core. But I like Joshua's idea of getting rid of contribs and pushing > them > >> out as any ot

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Jeff Janes
On Thu, May 28, 2015 at 11:01 PM, Fabien COELHO wrote: > > FWIW, I don't mind which one we put in core and which one we put out of >> core. But I like Joshua's idea of getting rid of contribs and pushing them >> out as any other extensions. >> > > Hmmm. > > I like the contrib directory as a livi

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Stephen Frost
* Joshua D. Drake (j...@commandprompt.com) wrote: > On 05/28/2015 11:01 PM, Fabien COELHO wrote: > >Also, removing a feature is a regression, and someone is always bound to > >complain... > > We aren't removing any features. These are all items that are NOT > installed or functional by default. U

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Joshua D. Drake
On 05/28/2015 11:08 PM, Pavel Stehule wrote: Hi I am not sure if PGXN can substitute contrib - mainly due deployment - It doesn't helps with MS Windows. Installing necessary software for compilation there is terrible. Anyone who is building for Windows won't have that problem. They already ha

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Joshua D. Drake
On 05/28/2015 11:01 PM, Fabien COELHO wrote: Also, removing a feature is a regression, and someone is always bound to complain... We aren't removing any features. These are all items that are NOT installed or functional by default. Sincerely, JD -- The most kicking donkey PostgreSQL Inf

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 11:02 GMT+02:00 Dave Page : > On Fri, May 29, 2015 at 9:55 AM, Pavel Stehule > wrote: > > > > > > 2015-05-29 10:37 GMT+02:00 Dave Page : > >> > >> On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule > > >> wrote: > >> > > >> > > >> > 2015-05-29 8:20 GMT+02:00 Guillaume Lelarge : > >> >> >

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Dave Page
On Fri, May 29, 2015 at 9:55 AM, Pavel Stehule wrote: > > > 2015-05-29 10:37 GMT+02:00 Dave Page : >> >> On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule >> wrote: >> > >> > >> > 2015-05-29 8:20 GMT+02:00 Guillaume Lelarge : >> >> >> >> Le 29 mai 2015 8:10 AM, "Pavel Stehule" a >> >> écrit >> >> :

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Michael Paquier
On Fri, May 29, 2015 at 5:52 PM, Pavel Stehule wrote: > > > 2015-05-29 10:40 GMT+02:00 Dave Page : >> >> On Fri, May 29, 2015 at 8:50 AM, Pavel Stehule >> wrote: >> > >> > >> > 2015-05-29 9:42 GMT+02:00 Michael Paquier : >> >> >> >> On Fri, May 29, 2015 at 4:11 PM, Pavel Stehule wrote: >> >> > 1.

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 10:37 GMT+02:00 Dave Page : > On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule > wrote: > > > > > > 2015-05-29 8:20 GMT+02:00 Guillaume Lelarge : > >> > >> Le 29 mai 2015 8:10 AM, "Pavel Stehule" a > écrit > >> : > >> > > >> > Hi > >> > > >> > I am not sure if PGXN can substitute contri

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 10:40 GMT+02:00 Dave Page : > On Fri, May 29, 2015 at 8:50 AM, Pavel Stehule > wrote: > > > > > > 2015-05-29 9:42 GMT+02:00 Michael Paquier : > >> > >> On Fri, May 29, 2015 at 4:11 PM, Pavel Stehule wrote: > >> > 1. VS requires relatively new MS Windows - problem for people with Ms > >

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Dave Page
On Fri, May 29, 2015 at 8:50 AM, Pavel Stehule wrote: > > > 2015-05-29 9:42 GMT+02:00 Michael Paquier : >> >> On Fri, May 29, 2015 at 4:11 PM, Pavel Stehule wrote: >> > 1. VS requires relatively new MS Windows - problem for people with Ms >> > Win 7 >> > and older >> >> Really, I use Win 2k8 stuff

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Dave Page
On Fri, May 29, 2015 at 9:35 AM, Dave Page wrote: > On Fri, May 29, 2015 at 7:20 AM, Guillaume Lelarge > wrote: >> Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit : >>> >>> Hi >>> >>> I am not sure if PGXN can substitute contrib - mainly due deployment - It >>> doesn't helps with MS Windows. Ins

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Dave Page
On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule wrote: > > > 2015-05-29 8:20 GMT+02:00 Guillaume Lelarge : >> >> Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit >> : >> > >> > Hi >> > >> > I am not sure if PGXN can substitute contrib - mainly due deployment - >> > It doesn't helps with MS Windows.

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Dave Page
On Fri, May 29, 2015 at 7:20 AM, Guillaume Lelarge wrote: > Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit : >> >> Hi >> >> I am not sure if PGXN can substitute contrib - mainly due deployment - It >> doesn't helps with MS Windows. Installing necessary software for compilation >> there is terrib

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 9:42 GMT+02:00 Michael Paquier : > On Fri, May 29, 2015 at 4:11 PM, Pavel Stehule wrote: > > 1. VS requires relatively new MS Windows - problem for people with Ms > Win 7 > > and older > > Really, I use Win 2k8 stuff and Win7 quite a lot. > On Win 7 you have to search and install now u

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Michael Paquier
On Fri, May 29, 2015 at 4:11 PM, Pavel Stehule wrote: > 1. VS requires relatively new MS Windows - problem for people with Ms Win 7 > and older Really, I use Win 2k8 stuff and Win7 quite a lot. > 2. After installation you have to find and apply some critical fixes - some > is bad documented. Exa

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 Thread Pavel Stehule
2015-05-29 8:54 GMT+02:00 Michael Paquier : > On Fri, May 29, 2015 at 3:20 PM, Guillaume Lelarge > wrote: > > Le 29 mai 2015 8:10 AM, "Pavel Stehule" a > écrit : > >> > >> Hi > >> > >> I am not sure if PGXN can substitute contrib - mainly due deployment - > It > >> doesn't helps with MS Windows.

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Michael Paquier
On Fri, May 29, 2015 at 3:20 PM, Guillaume Lelarge wrote: > Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit : >> >> Hi >> >> I am not sure if PGXN can substitute contrib - mainly due deployment - It >> doesn't helps with MS Windows. Installing necessary software for compilation >> there is terrib

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Pavel Stehule
2015-05-29 8:20 GMT+02:00 Guillaume Lelarge : > Le 29 mai 2015 8:10 AM, "Pavel Stehule" a > écrit : > > > > Hi > > > > I am not sure if PGXN can substitute contrib - mainly due deployment - > It doesn't helps with MS Windows. Installing necessary software for > compilation there is terrible. > >

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Guillaume Lelarge
Le 29 mai 2015 8:01 AM, "Fabien COELHO" a écrit : > > >> FWIW, I don't mind which one we put in core and which one we put out of >> core. But I like Joshua's idea of getting rid of contribs and pushing them >> out as any other extensions. > > > Hmmm. > > I like the contrib directory as a living ex

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Guillaume Lelarge
Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit : > > Hi > > I am not sure if PGXN can substitute contrib - mainly due deployment - It doesn't helps with MS Windows. Installing necessary software for compilation there is terrible. > I agree it's hard to compile an extension on Windows, but that's

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Pavel Stehule
Hi I am not sure if PGXN can substitute contrib - mainly due deployment - It doesn't helps with MS Windows. Installing necessary software for compilation there is terrible. Regards Pavel 2015-05-28 18:19 GMT+02:00 Joshua D. Drake : > > Hello, > > This is a topic that has come up in various way

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Fabien COELHO
FWIW, I don't mind which one we put in core and which one we put out of core. But I like Joshua's idea of getting rid of contribs and pushing them out as any other extensions. Hmmm. I like the contrib directory as a living example of "how to do an extension" directly available in the source

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Guillaume Lelarge
Le 29 mai 2015 5:33 AM, "Joshua D. Drake" a écrit : > > > On 05/28/2015 08:10 PM, Stephen Frost wrote: >> >> JD, > > This seems reasonable to me. It's in line with the recent move from contrib to bin. It'll just be quite a bit bigger of an undertaking. (50 threads to discuss the m

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Joshua D. Drake
On 05/28/2015 08:10 PM, Stephen Frost wrote: JD, This seems reasonable to me. It's in line with the recent move from contrib to bin. It'll just be quite a bit bigger of an undertaking. (50 threads to discuss the merits of each module separately?) Maybe start by picking the top 5 and sort t

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Stephen Frost
JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > On 05/28/2015 06:50 PM, Peter Eisentraut wrote: > >On 5/28/15 3:35 PM, Stephen Frost wrote: > >>What we would need for this is an 'extensions' directory, or similar, > >>and a clear definition of what the requirements are around getting into

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Amit Langote
On 2015-05-29 AM 11:14, Joshua D. Drake wrote: > > pg_trgm has been in contrib for a decade of not more. Either rip it out or > include it by default. > There are jsonb gin operator class related files in src/backend/utils/adt/. Perhaps, trgm_gin.c, trgm_gist.c, trgm_op.c could be moved there. S

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Joshua D. Drake
On 05/28/2015 06:50 PM, Peter Eisentraut wrote: On 5/28/15 3:35 PM, Stephen Frost wrote: What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module currently i

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Joshua D. Drake
On 05/28/2015 06:25 PM, Andrew Dunstan wrote: I'd be ok with installing it by default. But the case that's a lot harder to require to be always installed is pgcrypto, as has often been discussed in the past. It used to be but IIRC we don't have those restrictions anymore. If so, then we n

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Peter Eisentraut
On 5/28/15 3:35 PM, Stephen Frost wrote: > What we would need for this is an 'extensions' directory, or similar, > and a clear definition of what the requirements are around getting into > it are. With that, we could decide for each module currently in contrib > if it should go into the 'extension

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Andrew Dunstan
On 05/28/2015 04:22 PM, Joshua D. Drake wrote: On 05/28/2015 01:11 PM, Andrew Dunstan wrote: This seems to come up regularly. Maybe we should put it in an FAQ somewhere. The barriers to making non-core types into core types are very very high, possibly insurmountable. This is pretty much not

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Joshua D. Drake
On 05/28/2015 01:11 PM, Andrew Dunstan wrote: This seems to come up regularly. Maybe we should put it in an FAQ somewhere. The barriers to making non-core types into core types are very very high, possibly insurmountable. This is pretty much not an option. O.k., then either: * We install i

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Andrew Dunstan
On 05/28/2015 04:05 PM, Joshua D. Drake wrote: On 05/28/2015 12:35 PM, Stephen Frost wrote: JD, What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module c

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Joshua D. Drake
On 05/28/2015 12:35 PM, Stephen Frost wrote: JD, What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module currently in contrib if it should go into the 'ext

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Stephen Frost
JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > Contrib according to the docs is: > > "These include porting tools, analysis utilities, and plug-in > features that are not part of the core PostgreSQL system, mainly > because they address a limited audience or are too experimental to > be

[HACKERS] RFC: Remove contrib entirely

2015-05-28 Thread Joshua D. Drake
Hello, This is a topic that has come up in various ways over the years. After the long thread on pg_audit, I thought it might be time to bring it up again. Contrib according to the docs is: "These include porting tools, analysis utilities, and plug-in features that are not part of the core