On Wed, Jul 8, 2009 at 11:11 PM, Kasia Tuszynska wrote:
> Hello Postgres Hackers,
>
>
>
> We have begun testing Postgres 8.4 on windows, beginning with the installer.
> We have noticed that several additional modules which are usually installed
> through the Application Stack Wizard are missing fro
Hello Postgres Hackers,
We have begun testing Postgres 8.4 on windows, beginning with the installer. We
have noticed that several additional modules which are usually installed
through the Application Stack Wizard are missing from the list of available
modules like PostGIS or the developer opti
Hi,
D'Arcy J.M. Cain wrote:
...
Yes but what I am suggesting goes beyond that. My idea is that there
is a modules directory that contains a file for each installable
module. This file would contain all the information about the module
such as name, version, where to get the actual package, an
On Sat, 05 Apr 2008 09:18:07 +0200
PFC <[EMAIL PROTECTED]> wrote:
> But of course you need the ISP to do it for you if you are not
> superuser.
> Some will bother to run a few commands for a user, some won't...
Right. I encourage my competitors to do nothing for their clients. I
will co
On Sat, Apr 5, 2008 at 5:11 PM, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
> It even went so far that you could build the install/deinstall scripts
> into the module itself, so all postgres had to do was dlopen() the
> module it could access the install script. It fails due to the fact
>
On Fri, Apr 04, 2008 at 08:22:51PM -0400, Aidan Van Dyk wrote:
> Today was the first time I actually ever looked at the create function
> and create language code, and I'm actually suprised at how little
> "contract" there seems to be between a object file and the created
> function. But since it'
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Why wouldn't you just run it against template1 so that it is available
> in every database created after that?
Well maybe you don't want *every* customer to have it or not every customer
wants it. And also, what do you do about modules you add afte
On Sat, 05 Apr 2008 02:17:10 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
I was inclined to dismiss it myself but I think the point that's come
up here
is interesting. The ISP has to not just install an RPM or type make
install in
some source tree -- but actually log into each customer's dat
On Sat, 05 Apr 2008 02:17:10 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> I was inclined to dismiss it myself but I think the point that's come up here
> is interesting. The ISP has to not just install an RPM or type make install in
> some source tree -- but actually log into each customer's da
* Andrew Dunstan <[EMAIL PROTECTED]> [080404 21:54]:
> >Well, I'm happy to go back to lurking for now... Maybe after a few
> >years I'll have heard and seen more discussions and know better next
> >time ;-)
> Don't take it personally.
I don't, and for the record, I'm actually quite glad that th
Aidan Van Dyk wrote:
Unfortunately, the current state really does seem to mean that the
"feature of modularity" really is the kiss of death, since things are
actively pushed out from core to be modular projects, making them
unusable for most people...
Really? What have we pushed out that
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Fri, 4 Apr 2008 20:22:51 -0400
> Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>> Unfortunately, the current state really does seem to mean that the
>> "feature of modularity" really is the kiss of death, since things are
>> actively pushed out from
On Fri, 4 Apr 2008 20:22:51 -0400
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> Unfortunately, the current state really does seem to mean that the
> "feature of modularity" really is the kiss of death, since things are
> actively pushed out from core to be modular projects, making them
> unusable for
* Tom Lane <[EMAIL PROTECTED]> [080404 16:12]:
> And utterly, utterly insecure.
>
> The fact that the referenced object file is a "trusted" Postgres module
> isn't enough to make it safe --- the user can still play hob with the
> system by creating functions with the wrong argument/result types,
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> The example I have in mind is Perl, as I have referred to before. It comes
> with
> a number of useful modules (e.g. File::Find, and CGI) that don't have to be in
> the perl core distribution but are very widely used and so having them there
> makes
Tom Lane wrote:
IMHO, the ideal situation would be that the only stuff in contrib is
stuff that needs to be maintained together with the core code --- an
example is pg_controldata, because it looks at data structures that
we change on a frequent basis. We need to be looking for ways to
increa
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I would suggest a guc for the "safe" place and I would suggest it be a list
>> of
>> places. And I would suggest that for OS packagers they really want two
>> locations on that list, something like:
>> /usr/li
Gregory Stark <[EMAIL PROTECTED]> writes:
> I would suggest a guc for the "safe" place and I would suggest it be a list of
> places. And I would suggest that for OS packagers they really want two
> locations on that list, something like:
> /usr/lib/postgresql/modules;/usr/local/lib/postgresql/mod
Greg Smith <[EMAIL PROTECTED]> writes:
> On Thu, 3 Apr 2008, Joshua D. Drake wrote:
>> IMO the core modules should be compiled via configure with something
>> like:
>> ./configure --enable-module=ALL
> If you really want to make the problems with using contrib modules go
> away, so they are a) in
On Sat, Apr 5, 2008 at 12:22 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>
> > What if you didn't need super-user privileges to load "C" functions, on
> > the conditions that:
> > 1) There is no / in the obj_file filename (or some other "sanitizing"
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>> What if you didn't need super-user privileges to load "C" functions, on
>> the conditions that:
>> 1) There is no / in the obj_file filename (or some other "sanitizing"
>> rules)
>> 2) You're database owner
Assuming others think something like this might be interesting, would
something to do this be an OK candidate for my first patch, if only to
start this ball rolling?
a.
* Gregory Stark <[EMAIL PROTECTED]> [080404 14:57]:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>
> > What if you didn't need
"Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
> What if you didn't need super-user privileges to load "C" functions, on
> the conditions that:
> 1) There is no / in the obj_file filename (or some other "sanitizing"
>rules)
> 2) You're database owner
That's an interesting idea. It has the proper
Aidan Van Dyk wrote:
This was simply about changing the user permissions needed to run CREATE
FUNCTION ... LANGUAGE "C" so that distros/packages could have whatever
module they want packaged (in system RPM/DEB/PKG context) and available
on the system in a way that databases owners could instal
On Thu, 3 Apr 2008, Joshua D. Drake wrote:
IMO the core modules should be compiled via configure with something
like:
./configure --enable-module=ALL
If you really want to make the problems with using contrib modules go
away, so they are a) installed even by lazy ISPs who just do
compile/mak
* Andrew Dunstan <[EMAIL PROTECTED]> [080404 09:35]:
>
>
> Aidan Van Dyk wrote:
> >This changes the game slightly from trying to get systems to come with
> >PostreSQL "modules" installed into PostgreSQL by default, to where
> >systems come with PostgreSQL "module" *packages* (rpms, debs, pkg, etc
* Andrew Dunstan <[EMAIL PROTECTED]> [080404 10:17]:
> Aidan Van Dyk wrote:
> >This was simply about changing the user permissions needed to run CREATE
> >FUNCTION ... LANGUAGE "C" so that distros/packages could have whatever
> >module they want packaged (in system RPM/DEB/PKG context) and availa
* Jeremy Drake <[EMAIL PROTECTED]> [080404 01:27]:
> My opinion is, it doesn't matter what you call the modules/contrib stuff
> if I can't use it, and I can't use it if it is not loaded in my
> database, and I can't load it without superuser privileges.
Would it be possible to "change" the rules
Aidan Van Dyk wrote:
This changes the game slightly from trying to get systems to come with
PostreSQL "modules" installed into PostgreSQL by default, to where
systems come with PostgreSQL "module" *packages* (rpms, debs, pkg, etc)
installed by default, and the DB owners can do the "PostgreSQL i
On Fri, Apr 04, 2008 at 02:23:31PM +0530, Tom Dunstan wrote:
> Right. Which is why some of us have been suggesting a model where all
> modules currently in contrib are installed by default, but not enabled
> until a database owner actually issues some sort of "Install module
> foo" or whatever it l
On Fri, Apr 4, 2008 at 10:48 AM, Jeremy Drake <[EMAIL PROTECTED]> wrote:
> My opinion is, it doesn't matter what you call the modules/contrib stuff
> if I can't use it, and I can't use it if it is not loaded in my
> database, and I can't load it without superuser privileges.
Right. Which is w
On Thu, 3 Apr 2008, Peter Eisentraut wrote:
> Am Donnerstag, 3. April 2008 schrieb Andrew Dunstan:
> > If this were at all true we would not not have seen the complaints from
> > people along the lines of "My ISP won't install contrib". But we have,
> > and quite a number of times. We have concret
Joshua D. Drake wrote:
On Thu, 3 Apr 2008 13:54:11 -
"Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
Right now contrib is a real catch-all of various things; it would
be nice to categorize them somehow. And by categorize, I
emphatically do NOT mean move to pgfoundry, which is pretty much a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 12:03:43 -0700
Darcy Buskermolen <[EMAIL PROTECTED]> wrote:
> > This would install all the modules but not enable them in the
> > database itself (of course). This could also be extended to the pls
> > so that we have exactly one me
On Thursday 03 April 2008 08:47:12 Joshua D. Drake wrote:
> On Thu, 3 Apr 2008 21:03:05 +0530
>
> "Tom Dunstan" <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan <[EMAIL PROTECTED]>
> >
> > wrote:
> > > If this were at all true we would not not have seen the complaints
* Tom Dunstan <[EMAIL PROTECTED]> [080403 13:30]:
> As a side note, how were you intending to rename contrib? Directory
> shenanigans in CVS are horrible, particularly if you want all your
> old branches to still work.
Well, please, anybody doing this, just simply copy and use cvs remove and
cvs
D'Arcy J.M. Cain wrote:
On Thu, 03 Apr 2008 13:06:25 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
D'Arcy J.M. Cain wrote:
In fact, this may be the way to deprecate contrib. Start building
modules and move the contrib packages to it one at a time. That way
people using contrib hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 13:27:03 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> Well, OK, but given that this is a huge public project with lots of
> users expecting things to be in certain places, how fast do you think
> we could make such a chang
On Thu, Apr 3, 2008 at 10:36 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> No. I don't want to deprecate it, I want to get rid of it, lock, stock and
> barrel. If you think that we need more than renaming then we can discuss it,
> but I don't want a long death, I want one that is certain and swi
On Thu, 03 Apr 2008 13:06:25 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> D'Arcy J.M. Cain wrote:
> > In fact, this may be the way to deprecate contrib. Start building
> > modules and move the contrib packages to it one at a time. That way
> > people using contrib have some time to switch an
D'Arcy J.M. Cain wrote:
In fact, this may be the way to deprecate contrib. Start building
modules and move the contrib packages to it one at a time. That way
people using contrib have some time to switch and we can point people
to modules if they are just starting out.
Is there support for
On Thu, 03 Apr 2008 09:31:01 -0700
Ron Mayer <[EMAIL PROTECTED]> wrote:
> D'Arcy J.M. Cain wrote:
> > Check out NetBSD pkgsrc as a model. It is very flexible. One nice
> > thing would be the ability to specify where the packages are rather
> > than always insisting that they be on pgfoundry.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 12:46:30 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Apr 2008 09:41:57 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Thu, 3 Apr 2008 12:35:
On Apr 3, 2008, at 7:01 AM, Aidan Van Dyk wrote:
* Greg Sabino Mullane <[EMAIL PROTECTED]> [080403 09:54]:
Right now contrib is a real catch-all of various things; it would
be nice to
categorize them somehow. And by categorize, I emphatically do NOT
mean
move to pgfoundry, which is pretty
On Thu, 3 Apr 2008 09:41:57 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 3 Apr 2008 12:35:31 -0400
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 3 Apr 2008 13:54:11 -
> > "Greg Sabino Mullane" <[EMAIL PROTECT
Andrew Dunstan wrote:
>
>
> Ron Mayer wrote:
> > Andrew Dunstan wrote:
> >> Tom Lane wrote:
> >>> as having better system support for packages or modules or
> >>> whatever you want to call them; and maybe we also need some
> >>> marketing-type
> >>
> >> ...re-raise the question of getting rid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 12:35:31 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Apr 2008 13:54:11 -
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> > Right now contrib is a real catch-all of various things; it would
> > be nice t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2008, Joshua D. Drake wrote:
> "Tom Dunstan" wrote:
> >
> > One answer is: what do you do if some required library isn't
> > available?
>
>
> If we build by default, then when a library isn't found the configure
> output tells you:
>
>
On Thu, 3 Apr 2008 13:54:11 -
"Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> Right now contrib is a real catch-all of various things; it would be nice to
> categorize them somehow. And by categorize, I emphatically do NOT mean
> move to pgfoundry, which is pretty much a kiss of death.
Yes
D'Arcy J.M. Cain wrote:
Check out NetBSD pkgsrc as a model. It is very flexible. One nice
thing would be the ability to specify where the packages are rather
than always insisting that they be on pgfoundry.
Yup - a feature shared by RubyGems:
gem install rails –source http://gems.rubyonrai
Aidan Van Dyk wrote:
* Greg Sabino Mullane <[EMAIL PROTECTED]> [080403 09:54]:
I emphatically do NOT mean
move to pgfoundry, which is pretty much a kiss of death.
But that begs the question of *why* it's a kiss of death?
For instance, in "perl land", having something in "CPAN" and not in
"p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 21:45:52 +0530
"Tom Dunstan" <[EMAIL PROTECTED]> wrote:
> > This would install all the modules but not enable them in the
> > database itself (of course). This could also be extended to the pls
> > so that we have exactly one mecha
On Thu, Apr 3, 2008 at 9:17 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > It's hard to see ISPs who won't install contrib from installing
> > ${random module} from the big bad internet as has been discussed in
> > this thread, but who knows?
>
> Sure it is. The very word contrib brings abo
Am Donnerstag, 3. April 2008 schrieb Andrew Dunstan:
> If this were at all true we would not not have seen the complaints from
> people along the lines of "My ISP won't install contrib". But we have,
> and quite a number of times. We have concrete evidence that calling it
> contrib actually works a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Apr 2008 21:03:05 +0530
"Tom Dunstan" <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan <[EMAIL PROTECTED]>
> wrote:
>
> > If this were at all true we would not not have seen the complaints
> > from people along t
On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> If this were at all true we would not not have seen the complaints from
> people along the lines of "My ISP won't install contrib". But we have, and
> quite a number of times. We have concrete evidence that calling it con
Greg Sabino Mullane wrote:
At any rate, that's a bit blue sky right now. I haven't seen any
disagreement with our kissing "contrib" goodbye as a name, so let's work
on that. Unfortunately, that's going to involve a bit of pain,
Yes, I'm not sure I see the point of it. It's got a bad name
* Greg Sabino Mullane <[EMAIL PROTECTED]> [080403 09:54]:
> Right now contrib is a real catch-all of various things; it would be nice to
> categorize them somehow. And by categorize, I emphatically do NOT mean
> move to pgfoundry, which is pretty much a kiss of death.
But that begs the question
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> At any rate, that's a bit blue sky right now. I haven't seen any
> disagreement with our kissing "contrib" goodbye as a name, so let's work
> on that. Unfortunately, that's going to involve a bit of pain,
Yes, I'm not sure I see the point of
Zeugswetter Andreas OSB SD wrote:
The closest analogy to what I'm thinking is the perl CPAN
or ruby gems.
I think this is more a developer thing. I don't think an ISP would want
all that automagic (and certainly does not do that for joe user).
I think you are missing an ess
> > The closest analogy to what I'm thinking is the perl CPAN
> or ruby gems.
I think this is more a developer thing. I don't think an ISP would want
all that automagic (and certainly does not do that for joe user).
> One thing that might be worth looking at is an install command at the
> SQL
I had some thoughts about similar issues when looking at what it would
take to make pl/java yum-installable. The end goal was to be able to
say e.g. yum install pljava; echo "create language pljava;" | psql
mydb. Currently there's a non-trivial install process involving
running an sql script and ja
On Wed, 02 Apr 2008 20:15:49 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > I think it'd be especially cool if one could one-day have a command
> >
> > pg_install_module [modulename] -d [databasename]
> >
> > and it would magically get (or verify that it had) the latest
> > version from pgf
Andrew Dunstan wrote:
I think it'd be especially cool if one could one-day have a command
pg_install_module [modulename] -d [databasename]
Yes, and the CPAN analogy that has been in several minds, but it only
goes so far. Perl and Ruby are languages - Postgres is a very different
animal.
Ron Mayer wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
as having better system support for packages or modules or whatever
you want to call them; and maybe we also need some marketing-type
...re-raise the question of getting rid of contrib...
"The PostgreSQL Standard Modules".
While
Andrew Dunstan wrote:
Tom Lane wrote:
as having better system support for packages or modules or whatever
you want to call them; and maybe we also need some marketing-type
...re-raise the question of getting rid of contrib...
"The PostgreSQL Standard Modules".
While renaming, could we g
66 matches
Mail list logo
