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 m
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 (
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:
http://www.post
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
On Fri, Nov 18, 2011 at 9:35 AM, Tom Lane 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. Subdividing/rearranging
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
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 ad
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
> rig
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 visibly
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
On 11/18/11 12:27 PM, Dimitri Fontaine wrote:
> Tom Lane 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. Sub
Tom Lane 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 the packager's
>
Greg Smith 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 packagers would
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 t
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 pos
On Wed, Nov 16, 2011 at 9:20 AM, Dimitri Fontaine
wrote:
> Robert Haas 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,
Robert Haas 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 definition, more
On Tue, Nov 15, 2011 at 5:50 AM, Dimitri Fontaine
wrote:
> Thom Brown 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
>> "
Thom Brown 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 to them
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 h
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 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
On 15 November 2011 18:03, Robert Haas 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 the moment, becaus
Robert Haas wrote:
> Joshua Berkus 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.
By an international stand
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 t
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.
I
On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus 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 for kicki
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.
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
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
On Mon, Nov 14, 2011 at 8:44 PM, Greg Smith 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 first pass
> h
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
On 15 November 2011 00:56, 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 would regard the
> following as stable and of general utility:
> isn
I consider contrib/isn to be quite broken. It hard codes ISBN pre
On 15 November 2011 00:56, Josh Berkus 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
> fuzzy
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
uuid-oss
> 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
> wil
Thom Brown 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 from the manu
On 14 November 2011 09:08, Greg Smith 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 attempt to move som
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
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, Services,
On 14 October 2011 17:48, Bruce Momjian wrote:
>
> Is this going to be done for 9.2?
>
> ---
I didn't spot this thread before. I posted something related
yesterday: http://archives.postgresql.org/pgsql-hackers/2011-10/msg007
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 serious
On Sat, Jun 11, 2011 at 12:38 PM, Greg Smith 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 "extension".
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 bet
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 bre
Hi,
Greg Smith 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 decided to tentativ
Please do not piggyback on an unrelated thread to ask a question.
Start a new thread.
Vinicius Abrahao 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 file ...
have you ta
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 (right
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 cha
48 matches
Mail list logo
