On Wed, Jul 8, 2009 at 11:11 PM, Kasia Tuszynskaktuszyn...@esri.com 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
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
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 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
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
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 after
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's
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
that
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
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 why
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 looks
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
* 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 a bit
* 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 available
on
* 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)
installed
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
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 install
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 property that no
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
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
That's an
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
rules)
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) installed
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/modules
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:
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
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 some
* 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,
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 most
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 core to be
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
* 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 the bar
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
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
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
-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 it.
* 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 of
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,
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 contrib
-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 the lines of
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
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 about ideas
-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 mechanism to
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
perl
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
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! I
-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:
Looking for
-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 to categorize
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 of contrib...
The
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 PROTECTED] wrote:
Right
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
-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:31 -0400
D'Arcy
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.
Yup - a
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 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 and we can
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 swift.
-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 change.
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 have
* 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
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
from people
-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 mechanism
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
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 concrete
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 go
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:
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.
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 pgfoundry;
66 matches
Mail list logo
