Re: [HACKERS] Core Extensions relocation

2012-02-10 Thread Josh Berkus
All, Andrew ran crake on these modules, and they do not add any links not added by core postgres already. As such, can we proceed with this patch? Greg, do you have an updated version to run against HEAD? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers

Re: [HACKERS] Core Extensions relocation

2012-02-08 Thread Josh Berkus
Greg, This is currently awaiting a check by gsmith that the 7 named extensions do not add any new dependancies. Are you going to investigate this? If not, I'll give it a try this weekend. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Core Extensions relocation

2011-12-09 Thread Josh Berkus
All, This is currently awaiting a check by gsmith that the 7 named extensions do not add any new dependancies. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Core Extensions relocation

2011-11-29 Thread Josh Berkus
Tom, I think that if we move a few things into src/extension and set things up such that they get installed even if you just do make install rather than requiring make install-world, packagers who don't have any terribly strong personal agenda will decide that means they ought to be shipped

Re: [HACKERS] Core Extensions relocation

2011-11-21 Thread Bruce Momjian
Greg Smith wrote: I've submitted two changes to this CommitFest that are enhancing features in this core extensions set. Right now I have multiple customers who are desperate for both of those features. With extensions, I can give them changes that solve their immediate crisis right

Re: [HACKERS] Core Extensions relocation

2011-11-21 Thread Greg Smith
On 11/21/2011 11:40 AM, Bruce Momjian wrote: I think a question is how often people are waiting for features that actually can be addressed in a contrib/plugin way. My gut feeling is that most missing features have to be added to the server core (e.g. index-only scans) and are not possible to

Re: [HACKERS] Core Extensions relocation

2011-11-21 Thread Bruce Momjian
Greg Smith wrote: On 11/21/2011 11:40 AM, Bruce Momjian wrote: I think a question is how often people are waiting for features that actually can be addressed in a contrib/plugin way. My gut feeling is that most missing features have to be added to the server core (e.g. index-only scans)

Re: [HACKERS] Core Extensions relocation

2011-11-21 Thread Robert Haas
On Fri, Nov 18, 2011 at 9:35 AM, Tom Lane t...@sss.pgh.pa.us wrote: Why do you figure that, exactly?  The path of least resistance will be precisely to leave everything packaged as it is, in a single postgresql-contrib module.  I'm pretty likely to do that myself for Fedora and RHEL.  

Re: [HACKERS] Core Extensions relocation

2011-11-19 Thread Greg Smith
On 11/18/2011 03:36 PM, Josh Berkus wrote: Of course, packagers may then reasonably ask why that code is not just part of the core? Let me step back from the implementation ideas for a minute and talk about this, and how it ties into release philosophy. The extensions infrastructure for

Re: [HACKERS] Core Extensions relocation

2011-11-19 Thread Greg Smith
On 11/18/2011 09:35 AM, Tom Lane wrote: Subdividing/rearranging contrib makes the packager's life more complicated, *and* makes his users' lives more complicated, if only because things aren't where they were before. It seems unlikely to happen, at least in the near term. Users are

Re: [HACKERS] Core Extensions relocation

2011-11-18 Thread Greg Smith
On 11/17/2011 03:18 PM, Peter Eisentraut wrote: Who's to say that after this, the core extensions won't end up in a new separate package postgresql-extensions (or similar) or might even stay in postgresql-contrib, for compatibility? I don't know why packagers would make an active decision

Re: [HACKERS] Core Extensions relocation

2011-11-18 Thread Tom Lane
Greg Smith g...@2ndquadrant.com writes: On 11/17/2011 03:18 PM, Peter Eisentraut wrote: Who's to say that after this, the core extensions won't end up in a new separate package postgresql-extensions (or similar) or might even stay in postgresql-contrib, for compatibility? I don't know why

Re: [HACKERS] Core Extensions relocation

2011-11-18 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Why do you figure that, exactly? The path of least resistance will be precisely to leave everything packaged as it is, in a single postgresql-contrib module. I'm pretty likely to do that myself for Fedora and RHEL. Subdividing/rearranging contrib makes

Re: [HACKERS] Core Extensions relocation

2011-11-18 Thread Josh Berkus
On 11/18/11 12:27 PM, Dimitri Fontaine wrote: Tom Lane t...@sss.pgh.pa.us writes: Why do you figure that, exactly? The path of least resistance will be precisely to leave everything packaged as it is, in a single postgresql-contrib module. I'm pretty likely to do that myself for Fedora and

Re: [HACKERS] Core Extensions relocation

2011-11-17 Thread Peter Eisentraut
On mån, 2011-11-14 at 20:44 -0500, Greg Smith wrote: The very specific problem I was most concerned about eliminating was people discovering they needed an extension to troubleshoot performance or corruption issues, only to discover it wasn't available--because they hadn't installed the

Re: [HACKERS] Core Extensions relocation

2011-11-16 Thread Dimitri Fontaine
Thom Brown t...@linux.com writes: None of those others perform such a role. Instead they add additional functionality intended to be utilised as part of general data usage, adding new types, operators, query functions etc. Maybe the term core is inappropriate. Instead we might wish to refer

Re: [HACKERS] Core Extensions relocation

2011-11-16 Thread Robert Haas
On Tue, Nov 15, 2011 at 5:50 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Thom Brown t...@linux.com writes: None of those others perform such a role.  Instead they add additional functionality intended to be utilised as part of general data usage, adding new types, operators, query

Re: [HACKERS] Core Extensions relocation

2011-11-16 Thread Dimitri Fontaine
Robert Haas robertmh...@gmail.com writes: The term “core” here intends to show off that those extensions are maintained by the core PostgreSQL developer team. If needs be, those extensions will get updated in minor releases (crash, bugs, security, etc). Everything in contrib meets that

Re: [HACKERS] Core Extensions relocation

2011-11-16 Thread Robert Haas
On Wed, Nov 16, 2011 at 9:20 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Robert Haas robertmh...@gmail.com writes: The term “core” here intends to show off that those extensions are maintained by the core PostgreSQL developer team. If needs be, those extensions will get updated in minor

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Joshua Berkus
Greg, I'm not attached to the name, which I just pulled out of the air for the documentation. Could just as easily call them built-in modules or extensions. If the objection is that extensions isn't technically correct for auto-explain, you might call them core add-ons instead. My

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Joshua Berkus
Peter, I consider contrib/isn to be quite broken. It hard codes ISBN prefixes for the purposes of sanitising ISBNs, even though their assignment is actually controlled by a decentralised body of regional authorities. I'd vote for kicking it out of contrib. Submit a patch to fix it then.

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Robert Haas
On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus j...@agliodbs.com wrote: I consider contrib/isn to be quite broken. It hard codes ISBN prefixes for the purposes of sanitising ISBNs, even though their assignment is actually controlled by a decentralised body of regional authorities. I'd vote

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Greg Smith
On 11/15/2011 12:53 PM, Joshua Berkus wrote: Given discussion, is there any point in reporting on the actual patch yet? I don't expect the discussion will alter the code changes that are the main chunk of the patch here. The only place the most disputed parts impact is the documentation.

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Bruce Momjian
Robert Haas wrote: I use ISBN in 2 projects, and it's working fine for me. ?I'll strongly resist any attempt to kick it out. That's exactly why contrib is a random amalgamation of really useful stuff and utter crap: people feel justified in defending the continued existence of the crap

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote: Joshua Berkus j...@agliodbs.com wrote: I consider contrib/isn to be quite broken. It hard codes ISBN prefixes for the purposes of sanitising ISBNs, even though their assignment is actually controlled by a decentralised body of regional authorities.

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Peter Geoghegan
On 15 November 2011 18:03, Robert Haas robertmh...@gmail.com wrote: It's not fixable.  The ISBN datatype is the equivalent of having an SSN datatype that only allows SSNs that have actually been assigned to a US citizen. That isn't even the worst part. isn is basically only useful in the US at

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar nov 15 15:03:03 -0300 2011: On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus j...@agliodbs.com wrote: I consider contrib/isn to be quite broken. It hard codes ISBN prefixes for the purposes of sanitising ISBNs, even though their assignment is

Re: [HACKERS] Core Extensions relocation

2011-11-15 Thread Greg Smith
Well, this discussion veering off into ISN has certainly validated my gut feel that I should touch only the minimum number of things that kills my pain points, rather than trying any more ambitious restructuring. I hope that packaged extensions become so popular that some serious cutting can

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Thom Brown
On 14 November 2011 09:08, Greg Smith g...@2ndquadrant.com wrote: I've revived the corpose of the patch submitted in May, now that it's a much less strange time of the development cycle to consider it.  http://archives.postgresql.org/message-id/4df048bd.8040...@2ndquadrant.com was the first

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Dimitri Fontaine
Thom Brown t...@linux.com writes: I'm all for removing all mention of modules. It's ambiguous and used inconsistently. The module is the shared library object. It should be possible to use that consistently. And I have some plans on my TODO list about them anyway, so making them disappear

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Josh Berkus
This is a related problem, we should have a terminology for contrib tools such as pg_standby or pg_archivecleanup, for modules like the one you talk about, that provide new features but nothing visible from SQL, and extensions, that are all about SQL --- and if I can work on my plans will

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Josh Berkus
Greg, So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions. I would regard the following as stable and of general utility: btree_gin btree_gist citext dblink file_fdw fuzzystrmatch hstore intarray isn ltree pgcrypto pg_trgm unaccent

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Thom Brown
On 15 November 2011 00:56, Josh Berkus j...@agliodbs.com wrote: Greg, So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions.  I would regard the following as stable and of general utility: btree_gin btree_gist citext dblink file_fdw

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Peter Geoghegan
On 15 November 2011 00:56, Josh Berkus j...@agliodbs.com wrote: So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions.  I would regard the following as stable and of general utility: isn I consider contrib/isn to be quite broken. It hard

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Greg Smith
On 11/14/2011 07:56 PM, Josh Berkus wrote: So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions. I was aiming for the extensions that seemed uncontroversial for a first pass here. One of the tests I applied was do people sometimes need

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Robert Haas
On Mon, Nov 14, 2011 at 8:44 PM, Greg Smith g...@2ndquadrant.com wrote: On 11/14/2011 07:56 PM, Josh Berkus wrote: So I'm a bit unclear on why most of the optional data types were excluded from your list of Core Extensions. I was aiming for the extensions that seemed uncontroversial for a

Re: [HACKERS] Core Extensions relocation

2011-11-14 Thread Greg Smith
On 11/14/2011 10:09 PM, Robert Haas wrote: I continue to think that we should be trying to sort these by subject matter. The term core extensions doesn't convey that these are server management and debugging tools, hence Josh's confusion. I'm not attached to the name, which I just pulled

Re: [HACKERS] Core Extensions relocation

2011-11-02 Thread Greg Smith
On 10/14/2011 01:48 PM, Bruce Momjian wrote: Is this going to be done for 9.2? Refreshing this patch is on my list of things to finish before the next CommitFest starts later this month. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training,

Re: [HACKERS] Core Extensions relocation

2011-11-02 Thread Josh Berkus
On 11/2/11 8:25 AM, Greg Smith wrote: On 10/14/2011 01:48 PM, Bruce Momjian wrote: Is this going to be done for 9.2? Refreshing this patch is on my list of things to finish before the next CommitFest starts later this month. Put me down as reviewer. -- Josh Berkus PostgreSQL Experts

Re: [HACKERS] Core Extensions relocation

2011-10-14 Thread Bruce Momjian
Is this going to be done for 9.2? --- Greg Smith wrote: Following up on the idea we've been exploring for making some extensions more prominent, attached is the first rev that I think may be worth considering

Re: [HACKERS] Core Extensions relocation

2011-10-14 Thread Thom Brown
On 14 October 2011 17:48, Bruce Momjian br...@momjian.us wrote: Is this going to be done for 9.2? --- I didn't spot this thread before. I posted something related yesterday:

Re: [HACKERS] Core Extensions relocation

2011-07-05 Thread Robert Haas
On Sat, Jun 11, 2011 at 12:38 PM, Greg Smith g...@2ndquadrant.com wrote: Peter Eisentraut wrote: For the directory name, I'd prefer either src/extensions (since there is more than one), or if you want to go for short somehow, src/ext.  (Hmm, I guess the installation subdirectory is also called

Re: [HACKERS] Core Extensions relocation

2011-06-11 Thread Greg Smith
Peter Eisentraut wrote: For the directory name, I'd prefer either src/extensions (since there is more than one), or if you want to go for short somehow, src/ext. (Hmm, I guess the installation subdirectory is also called extension. But it felt wrong on first reading anyway.) I jumped

Re: [HACKERS] Core Extensions relocation

2011-06-10 Thread Dimitri Fontaine
Hi, Greg Smith g...@2ndquadrant.com writes: Following up on the idea we've been exploring for making some extensions more prominent, attached is the first rev that I think may be worth considering seriously. Main improvement from the last is that I reorganized the docs to break out what I

Re: [HACKERS] Core Extensions relocation

2011-06-10 Thread Peter Eisentraut
On tor, 2011-06-09 at 00:14 -0400, Greg Smith wrote: Following up on the idea we've been exploring for making some extensions more prominent, attached is the first rev that I think may be worth considering seriously. Main improvement from the last is that I reorganized the docs to break

Re: [HACKERS] Core Extensions relocation

2011-06-09 Thread Vinicius Abrahao
Hello Greg, hello All, This is my first post at Hackers, so sorry if I am been a noob here, but I am pretty confused about how to create the extension pg_buffercache. First of all, I was trying to create using the old method by calling the pg_buffercache--1.0.sql directly. Then I discover the

Re: [HACKERS] Core Extensions relocation

2011-06-09 Thread Greg Smith
Vinicius Abrahao wrote: This is my first post at Hackers, so sorry if I am been a noob here, but I am pretty confused about how to create the extension pg_buffercache. This list is for talking about development of new features, normally on the latest development version of the software

Re: [HACKERS] Core Extensions relocation

2011-06-09 Thread Tom Lane
Please do not piggyback on an unrelated thread to ask a question. Start a new thread. Vinicius Abrahao vinnix@gmail.com writes: postgres=# CREATE EXTENSION pg_buffercache SCHEMA pg_catalog; ERROR: syntax error at or near NO This looks like a syntax error in the pg_buffercache--1.0.sql