On Mon, 2014-03-10 at 09:36 +0100, Dimitri Fontaine wrote:
Please find attached the v2 version of the patch, including fixes for
the crash and documentation aspects you've listed before.
Do we want to get this version committed (will need some small tweaks),
or do we want to wait for the next
* Peter Eisentraut (pete...@gmx.net) wrote:
On Mon, 2014-03-10 at 09:36 +0100, Dimitri Fontaine wrote:
Please find attached the v2 version of the patch, including fixes for
the crash and documentation aspects you've listed before.
Do we want to get this version committed (will need some
Peter Eisentraut pete...@gmx.net writes:
On Mon, 2014-03-10 at 09:36 +0100, Dimitri Fontaine wrote:
Please find attached the v2 version of the patch, including fixes for
the crash and documentation aspects you've listed before.
Do we want to get this version committed (will need some small
Peter Eisentraut pete...@gmx.net writes:
Aside from those details, it seems clear that any reasonably complete
move-extensions-elsewhere feature will need some kind of build system
support. I have various ideas on that and would gladly contribute some
of them, but it's not going to happen
On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut pete...@gmx.net wrote:
What the $directory proposal achieves is allowing a fully relocatable
extension layout, where you just have to drop a directory anywhere in
the file system and it just works (*).
If that's what you want (and it sounds
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut pete...@gmx.net wrote:
What the $directory proposal achieves is allowing a fully relocatable
extension layout, where you just have to drop a directory anywhere in
the file system and it just works
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
What about allowing a control file like this:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
What about allowing a control file like this:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
Hi,
Peter Eisentraut pete...@gmx.net writes:
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
I think your previously proposed patch to add extension_control_path
plus my suggestion to update existing de facto best
On 3/7/14, 11:39 AM, Dimitri Fontaine wrote:
Just please make sure that it's still possible to use full absolute path
for the module path name so that the packager can have control too.
I can't think of any package system where absolute paths are part of a
recommended workflow. There is always
[I answered most of these concerns in more detail in the reply to Dimitri.]
On 3/7/14, 9:16 AM, Stephen Frost wrote:
Being able to have a self-contained module which requires a minimum of
modification to postgresql.conf is a reduction in complexity, imv.
Having to maintain two config options
Peter Eisentraut pete...@gmx.net writes:
I think we should get rid of the module_pathname business, and
extensions' SQL files should just refer to the base file name and rely
on the dynamic library path to find the files. What would we lose if we
did that?
Control over *which* mylib.so file
Stephen Frost sfr...@snowman.net writes:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
relocatable = true
Interesting idea. I'm a *little*
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Peter Eisentraut pete...@gmx.net writes:
I think we should get rid of the module_pathname business, and
extensions' SQL files should just refer to the base file name and rely
on the dynamic library path to find the files. What would we
Stephen Frost sfr...@snowman.net writes:
Yeah, default_version was the other one that looked like it might be
possible to include, but folks might decide to try and use 'comment' in
that way too. Basically, there's a chance that they'd want to use any
string in there.
Actually, I think that
Stephen Frost sfr...@snowman.net writes:
I'm a bit confused here- above you '+1'd packagers/sysadmins, but then
here you are saying that hackers will be setting it? Also, it strikes
Well I was then talking about how it works today, as in PostgreSQL 9.1,
9.2 and 9.3, and most certainly 9.4 as
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
me as a terrible idea to ship absolute object file names (which I assume
you mean to include path, given you say 'absolute') unless you're an
I agree, that's why my current design also needs
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
What about allowing a control file like this:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
module_pathname = '$directory/hstore'
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
What about allowing a control file like this:
# hstore extension
comment = 'data type for storing sets of (key, value) pairs'
default_version = '1.3'
directory = 'local/hstore-new'
Hi,
Peter Eisentraut pete...@gmx.net writes:
I'm massively in favor of this feature. (I had started writing it about
three times myself.)
Thanks!
The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Peter Eisentraut pete...@gmx.net writes:
The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
files will still end up pointing to a not
Stephen Frost sfr...@snowman.net writes:
This is true and Debian puts the control/sql files into a different
directory than the .so files, of course. Still, the issue here is how
we find the .so files- the user *has* to tell us where the control file
is, if it isn't in the default location,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
The rules that PostgreSQL follows to know where to load the library from
are not changed *at all* by this patch. In my book, it makes the whole
topic irrelevant to the review.
I'm really quite tired of the constant dismissal of anything
Stephen Frost sfr...@snowman.net writes:
I didn't suggest anywhere that the proposed patch changed the rules at
all- instead I was trying to point out that by adding this functionality
and *not* changing the way that lookup is done *is going to cause
confusion*.
I don't see any confusion
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
I don't see any confusion about dynamic library name resolving added
from the extension_control_path, I'm sorry. Simply because I don't
expect people to use the facility without a third party software
designed to fill-in the gap.
You're
Stephen Frost sfr...@snowman.net writes:
I find this role reversal to be quite bizarre.
Who do you think should have a say about where to load the dynamic
librairies from? hackers, packagers, system admins, dbas or users?
Who do you think is currently editing the setup that decides where to
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Who do you think should have a say about where to load the dynamic
librairies from? hackers, packagers, system admins, dbas or users?
My gut feeling on this is packages and sysadmins. Do you see it
differently? I generally *don't* think
Stephen Frost sfr...@snowman.net writes:
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Who do you think should have a say about where to load the dynamic
librairies from? hackers, packagers, system admins, dbas or users?
My gut feeling on this is packages and sysadmins. Do you see it
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Stephen Frost sfr...@snowman.net writes:
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Who do you think should have a say about where to load the dynamic
librairies from? hackers, packagers, system admins, dbas or users?
My gut
I'm massively in favor of this feature. (I had started writing it about
three times myself.)
The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
files will still end up pointing to a not relocated library
* Peter Eisentraut (pete...@gmx.net) wrote:
I'm massively in favor of this feature. (I had started writing it about
three times myself.)
Agreed.
The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
Hi,
On 06/02/14 18:14, Greg Stark wrote:
Installing into /usr/local is a global system change. Only root should
be able to do that and any user that can do that can easily acquire
root privileges.
The idea behind Homebrew is copied from FreeBSD, where you also
install 3rd party software to
On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler da...@justatheory.com wrote:
The install failed, of course, because extensions want to install in
$PGROOT/share/extensions.
Homebrew sounds kind of confused. Having a non-root user have access
to make global system changes sounds like privilege
* Greg Stark (st...@mit.edu) wrote:
On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler da...@justatheory.com
wrote:
The install failed, of course, because extensions want to install in
$PGROOT/share/extensions.
Homebrew sounds kind of confused. Having a non-root user have access
to make
On Feb 6, 2014, at 6:51 AM, Greg Stark st...@mit.edu wrote:
Homebrew sounds kind of confused. Having a non-root user have access
to make global system changes sounds like privilege escalation
vulnerability by design.
Well, the point is that it *doesn’t* make global system changes. I got an
On Feb 6, 2014, at 7:32 AM, Stephen Frost sfr...@snowman.net wrote:
The end-admin would have to modify the system-installed postgresql.conf
anyway to enable this other directory. David wasn't suggesting that
Homebrew *should* be able to do so, he was pointing out that it *can't*,
which all
On Thu, Feb 6, 2014 at 5:49 PM, David E. Wheeler da...@justatheory.com wrote:
On Feb 6, 2014, at 6:51 AM, Greg Stark st...@mit.edu wrote:
Homebrew sounds kind of confused. Having a non-root user have access
to make global system changes sounds like privilege escalation
vulnerability by
On Feb 6, 2014, at 9:14 AM, Greg Stark st...@mit.edu wrote:
Installing into /usr/local is a global system change. Only root should
be able to do that and any user that can do that can easily acquire
root privileges.
I agree with you, but I don’t think the Homebrew folks do. Or at least their
On Jan 30, 2014, at 10:06 AM, Sergey Muraviov sergey.k.murav...@gmail.com
wrote:
Now it looks fine for me.
Just as another data point, I recently submitted pgTAP to the Homebrew project
This is the build-from-source system for OS X, used by a lot of web developers.
In my build script, I
Hi.
Now it looks fine for me.
2014-01-28 Dimitri Fontaine dimi...@2ndquadrant.fr:
Hi,
Sergey Muraviov sergey.k.murav...@gmail.com writes:
Now patch applies cleanly and works. :-)
Cool ;-)
But I have some notes:
1. There is an odd underscore character in functions
Hi,
Sergey Muraviov sergey.k.murav...@gmail.com writes:
Now patch applies cleanly and works. :-)
Cool ;-)
But I have some notes:
1. There is an odd underscore character in functions
find_in_extension_control_path and list_extension_control_paths:
\extension_control__path\
Fixed in the
I haven't actually looked at the patch itself, but I noted this from the
other review:
On Fri, Jan 24, 2014 at 6:43 PM, Sergey Muraviov
sergey.k.murav...@gmail.com wrote:
=
postgresql.conf:
extension_control_path =
Magnus Hagander mag...@hagander.net writes:
Using colon as the path separator is going to break on windows. The patch
notices this and uses semicolon on Windows instead. Do we really want to go
down that path - that means that everybody who writes any sorts of
installation instructions
Magnus Hagander mag...@hagander.net writes:
Using colon as the path separator is going to break on windows. The patch
notices this and uses semicolon on Windows instead. Do we really want to go
down that path - that means that everybody who writes any sorts of
installation instructions
On Sat, Jan 25, 2014 at 6:07 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Magnus Hagander mag...@hagander.net writes:
Using colon as the path separator is going to break on windows. The patch
notices this and uses semicolon on Windows instead. Do we really want to
go
down that path -
Sergey Muraviov sergey.k.murav...@gmail.com writes:
I can't apply the patch.
Did you try using the `patch`(1) command?
The PostgreSQL project policy is to not use the git format when sending
patches to the mailing list, prefering the context diff format. So you
need to resort to using the basic
On Fri, Jan 24, 2014 at 6:57 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Sergey Muraviov sergey.k.murav...@gmail.com writes:
I can't apply the patch.
Did you try using the `patch`(1) command?
The PostgreSQL project policy is to not use the git format when sending
patches to the
Hi
Now patch applies cleanly and works. :-)
But I have some notes:
1. There is an odd underscore character in functions
find_in_extension_control_path and list_extension_control_paths:
\extension_control__path\
2. If we have several versions of one extension in different directories
(which are
On Fri, Jan 24, 2014 at 6:57 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Would be nice if we can use git apply command...
git apply seems to have raised pedantry to an art form. Not only
won't it apply patches in any format other than the one it likes,
it'll fail to apply any
Hi.
I can't apply the patch.
$ git apply --stat ~/Downloads/extension_control_path.v0.patch
fatal: unrecognized input
2014/1/14 Dimitri Fontaine dimi...@2ndquadrant.fr
Hi,
Please find attached to this email a patch implementing a new GUC that
allows users to setup a list of path where
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Please find attached to this email a patch implementing a new GUC that
allows users to setup a list of path where PostgreSQL will search for
the extension control files at CREATE EXTENSION time.
Why is that a good idea? It's certainly not going
Tom Lane t...@sss.pgh.pa.us writes:
Why is that a good idea? It's certainly not going to simplify DBAs'
lives, more the reverse. (This dump won't reload. Uh, where did
you get that extension from? Ummm...)
The latest users for the feature are the Red Hat team working on Open
Shift where they
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Please find attached to this email a patch implementing a new GUC that
allows users to setup a list of path where PostgreSQL will search for
the extension control files at CREATE EXTENSION time.
Why is
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Why is that a good idea? It's certainly not going to simplify DBAs'
lives, more the reverse. (This dump won't reload. Uh, where did
you get that extension from? Ummm...)
The latest users for the feature are
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Why is that a good idea? It's certainly not going to simplify DBAs'
lives, more the reverse. (This dump won't reload. Uh, where did
you get that extension from? Ummm...)
But you can have a single $SHAREDIR per set of executables, right?
Please read the following email to know what they asked for and how they
do operate OpenShift:
http://www.postgresql.org/message-id/341087492.2585530.1376776393038.javamail.r...@redhat.com
FWIW, I'm talking with
On 15 January 2014 03:07, Stephen Frost sfr...@snowman.net wrote:
For my 2c, I could absolutely see it as being worthwhile to have an
independent directory to install not-from-package extensions. That
would keep things which are managed by the package system and things
which are installed
58 matches
Mail list logo
