Peter Eisentraut 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 tweaks),
> o
* 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 s
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
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut 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 Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut 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 attractive
Peter Eisentraut 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 within two week
[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
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 alway
Hi,
Peter Eisentraut 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 practices to
* 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/hs
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'
>
Stephen Frost 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 $default_value
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Peter Eisentraut 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
>
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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'
> >>re
Stephen Frost 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* concerned
Peter Eisentraut 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 gets loaded
* 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/hs
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'
>
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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 cooperation on the
Stephen Frost 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 we're not trying t
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost 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
Stephen Frost 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
+1
>> Who d
* 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 DBA
Stephen Frost 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
load the dynamic lib
* 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'r
Stephen Frost 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 about dynamic libra
* 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 brou
Stephen Frost 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, and the assumpti
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Peter Eisentraut 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 relocated libra
Hi,
Peter Eisentraut 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
> files will st
* 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
>
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 fil
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 Feb 6, 2014, at 9:14 AM, 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.
I agree with you, but I don’t think the Homebrew folks do. Or at least their
current im
On Thu, Feb 6, 2014 at 5:49 PM, David E. Wheeler wrote:
> On Feb 6, 2014, at 6:51 AM, Greg Stark 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 th
On Feb 6, 2014, at 7:32 AM, Stephen Frost 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 makes sense imv.
On Feb 6, 2014, at 6:51 AM, Greg Stark 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 error
on OS
* Greg Stark (st...@mit.edu) wrote:
> On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler
> 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
On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler 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 escalation
vulnerabi
On Jan 30, 2014, at 10:06 AM, Sergey Muraviov
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 originally had
depends_on :
Hi.
Now it looks fine for me.
2014-01-28 Dimitri Fontaine :
> Hi,
>
> Sergey Muraviov 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
Hi,
Sergey Muraviov 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 new version of the pa
On Sat, Jan 25, 2014 at 6:07 PM, Dimitri Fontaine wrote:
> Magnus Hagander 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 wri
Magnus Hagander 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 including this will hav
Magnus Hagander 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 including this will hav
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 =
> '/extensions/post
On Fri, Jan 24, 2014 at 6:57 AM, Fabrízio de Royes Mello
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 part of the patch if t
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 a
On Fri, Jan 24, 2014 at 6:57 AM, Dimitri Fontaine
wrote:
>
> Sergey Muraviov 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 for
Sergey Muraviov 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 patch commands rather than
Hi.
I can't apply the patch.
$ git apply --stat ~/Downloads/extension_control_path.v0.patch
fatal: unrecognized input
2014/1/14 Dimitri Fontaine
> Hi,
>
> 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
On 15 January 2014 03:07, Stephen Frost 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 independent sepa
> 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
Tom Lane writes:
> Dimitri Fontaine writes:
>> Tom Lane 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
Dimitri Fontaine writes:
> Tom Lane 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 o
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dimitri Fontaine 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 i
Tom Lane 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 want to h
Dimitri Fontaine 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 to simplify DBAs'
li
58 matches
Mail list logo
