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
On Thu, Jun 4, 2015 at 2:33 PM, Joshua D. Drake j...@commandprompt.com 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
On 29 May 2015 at 02:50, Peter Eisentraut pete...@gmx.net 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
On Fri, Jun 5, 2015 at 8:32 AM, Stephen Frost sfr...@snowman.net 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
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Jun 4, 2015 at 2:33 PM, Joshua D. Drake j...@commandprompt.com
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,
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
On Jun 5, 2015, at 12:34 AM, Jim Nasby jim.na...@bluetreble.com 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
On Jun 4, 2015, at 3:11 PM, David E. Wheeler da...@justatheory.com wrote:
On Jun 4, 2015, at 11:53 AM, Neil Tiffin ne...@neiltiffin.com 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
On Thu, Jun 04, 2015 at 01:11:21PM -0700, David E. Wheeler wrote:
On Jun 4, 2015, at 11:53 AM, Neil Tiffin ne...@neiltiffin.com 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
On Fri, Jun 5, 2015 at 7:42 AM, Joshua D. Drake j...@commandprompt.com
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
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
On Fri, Jun 5, 2015 at 02:42:45PM +0100, Simon Riggs wrote:
On 29 May 2015 at 02:50, Peter Eisentraut pete...@gmx.net 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
On 06/04/2015 10:34 AM, Robert Haas wrote:
On Thu, Jun 4, 2015 at 11:49 AM, Joshua D. Drake j...@commandprompt.com 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
On Thu, Jun 4, 2015 at 1:57 PM, Joshua D. Drake j...@commandprompt.com 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
On Thu, Jun 4, 2015 at 11:49 AM, Joshua D. Drake j...@commandprompt.com 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
On 06/04/2015 11:01 AM, Robert Haas wrote:
On Thu, Jun 4, 2015 at 1:57 PM, Joshua D. Drake j...@commandprompt.com 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
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 of core
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 out of
On Jun 4, 2015, at 11:53 AM, Neil Tiffin ne...@neiltiffin.com 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
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.
On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan and...@dunslane.net 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
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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan and...@dunslane.net 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
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
On 6/4/15 10:30 AM, Robert Haas wrote:
On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstanand...@dunslane.net 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
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
On Fri, May 29, 2015 at 10:30 AM, Stephen Frost sfr...@snowman.net 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
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
On Jun 4, 2015, at 10:55 AM, Jim Nasby jim.na...@bluetreble.com 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
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
need to
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 behavior
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 that
On Fri, May 29, 2015 at 5:52 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-05-29 10:40 GMT+02:00 Dave Page dp...@pgadmin.org:
On Fri, May 29, 2015 at 8:50 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-05-29 9:42 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:
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.
On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-05-29 8:20 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com a écrit
:
Hi
I am not sure if PGXN can substitute contrib - mainly due
On Fri, May 29, 2015 at 8:50 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-05-29 9:42 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:
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
On Fri, May 29, 2015 at 9:35 AM, Dave Page dp...@pgadmin.org wrote:
On Fri, May 29, 2015 at 7:20 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com a écrit :
Hi
I am not sure if PGXN can substitute contrib - mainly due
2015-05-29 10:40 GMT+02:00 Dave Page dp...@pgadmin.org:
On Fri, May 29, 2015 at 8:50 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-05-29 9:42 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:
On Fri, May 29, 2015 at 4:11 PM, Pavel Stehule wrote:
1. VS requires relatively
2015-05-29 9:42 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:
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
On Fri, May 29, 2015 at 7:20 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com 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
2015-05-29 10:37 GMT+02:00 Dave Page dp...@pgadmin.org:
On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-05-29 8:20 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com a
écrit
:
Hi
On Fri, May 29, 2015 at 9:55 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-05-29 10:37 GMT+02:00 Dave Page dp...@pgadmin.org:
On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-05-29 8:20 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
Le
On Fri, May 29, 2015 at 3:20 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com 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
2015-05-29 8:54 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:
On Fri, May 29, 2015 at 3:20 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com a
écrit :
Hi
I am not sure if PGXN can substitute contrib - mainly due
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
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com 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
2015-05-29 8:20 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
Le 29 mai 2015 8:10 AM, Pavel Stehule pavel.steh...@gmail.com 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
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 j...@commandprompt.com:
Hello,
This is a topic that has
Le 29 mai 2015 8:01 AM, Fabien COELHO coe...@cri.ensmp.fr 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
2015-05-29 11:02 GMT+02:00 Dave Page dp...@pgadmin.org:
On Fri, May 29, 2015 at 9:55 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-05-29 10:37 GMT+02:00 Dave Page dp...@pgadmin.org:
On Fri, May 29, 2015 at 7:27 AM, Pavel Stehule pavel.steh...@gmail.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.
Sincerely,
JD
--
The most kicking donkey PostgreSQL
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
On Thu, May 28, 2015 at 11:26 PM, Guillaume Lelarge guilla...@lelarge.info
wrote:
Le 29 mai 2015 8:01 AM, Fabien COELHO coe...@cri.ensmp.fr 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
On Thu, May 28, 2015 at 11:01 PM, Fabien COELHO coe...@cri.ensmp.fr 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
On Fri, May 29, 2015 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us 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
Peter Geoghegan p...@heroku.com 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.
On Fri, May 29, 2015 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us 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
On 05/29/2015 02:54 PM, Tom Lane wrote:
Peter Geoghegan p...@heroku.com 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
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
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
2015-05-29 21:59 GMT+02:00 Joshua D. Drake j...@commandprompt.com:
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
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,
* 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.
Uh,
On 05/29/2015 02:08 PM, Peter Geoghegan wrote:
On Fri, May 29, 2015 at 11:47 AM, Josh Berkus j...@agliodbs.com 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,
On Fri, May 29, 2015 at 11:47 AM, Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
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
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
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
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 part
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
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
it are.
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 'extensions'
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
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
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.
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
Le 29 mai 2015 5:33 AM, Joshua D. Drake j...@commandprompt.com 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
78 matches
Mail list logo
