On 07/02/2015 11:37 PM, Oskari Saarenmaa wrote:
I'm somewhat interested in both #1 & #2 for other projects, but I wrote
this patch to address #3, i.e. to simplify the test setup we have in
place for pgmemcache
(https://github.com/ohmu/pgmemcache/blob/master/localtests.sh) and other
extensions. I'
02.07.2015, 20:31, Heikki Linnakangas kirjoitti:
> On 03/04/2015 09:41 AM, Oskari Saarenmaa wrote:
>> 18.02.2015, 01:49, Jim Nasby kirjoitti:
>>> On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
Here's a patch to allow overriding extension installation directory.
The patch allows superusers to
On 03/04/2015 09:41 AM, Oskari Saarenmaa wrote:
18.02.2015, 01:49, Jim Nasby kirjoitti:
On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
Andres Freund writes:
In any case, no packager is going to ship an insecure-by-default
configuration, which is wh
On 3/4/15 1:41 AM, Oskari Saarenmaa wrote:
>I'm interested in this because it could potentially make it possible to
>install SQL extensions without OS access. (My understanding is there's
>some issue with writing the extension files even if LIBDIR is writable
>by the OS account).
I'm not sure th
18.02.2015, 01:49, Jim Nasby kirjoitti:
> On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
>> 10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
>>> Andres Freund writes:
> In any case, no packager is going to ship an insecure-by-default
> configuration, which is what Dimitri seems to be fantasizin
On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
Andres Freund writes:
In any case, no packager is going to ship an insecure-by-default
configuration, which is what Dimitri seems to be fantasizing would
happen. It would have to be local option to rela
10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
> Andres Freund writes:
>>> In any case, no packager is going to ship an insecure-by-default
>>> configuration, which is what Dimitri seems to be fantasizing would
>>> happen. It would have to be local option to relax the permissions
>>> on the direc
Craig Ringer writes:
> On 06/12/2013 02:24 PM, Tom Dunstan wrote:
>> Oh, interesting. Do the ruby/rails folks use that rather than a pure-ruby
>> driver? I guess I'm spoiled - most of my development happens on the JVM,
>> and the JDBC driver doesn't use libpq.
> Yes, they do - including a horde o
On 12 June 2013 17:30, Dave Page wrote:
> Messing with the path (or the dynamic load path) can cause all sorts
> of fun and interesting problems for users, as we found in the early
> days with the EDB installers. I realise it doesn't help these users
> (who doubtless don't know it exists) but wha
On Wed, Jun 12, 2013 at 7:24 AM, Tom Dunstan wrote:
>
> Another alternative is for the Postgres.app to add its bin dir to the user's
> (or system's) path on first startup. Then the correct pg_config will be
> found (and the correct psql, pgdump etc etc as well). The app could in
> theory even go l
On 12 June 2013 16:30, Craig Ringer wrote:
> None of this is hard if you have clue what you're doing. Rebuild the Pg
> gem against the right libpq by fixing your PATH so it finds the right
> pg_config, set host=/tmp, or set host=localhost. Any of the three will
> work. Unfortunately most of thes
On 12 June 2013 16:12, Craig Ringer wrote:
> Yes, they do - including a horde of deeply confused and frustrated Rails
> users struggling to understand why they're getting "no such file or
> directory" or "permission denied" messages about Pg's unix socket,
> because of course they're linked to Ap
On 06/12/2013 02:52 PM, Peter Geoghegan wrote:
> On Tue, Jun 11, 2013 at 11:42 PM, Craig Ringer wrote:
>> Anyway, point being that PostgreSQL from Macports, Homebrew, and/or
>> EnterpriseDB's installer might be present ... and even in use.
> Perhaps you should direct those users towards http://pos
On Tue, Jun 11, 2013 at 11:42 PM, Craig Ringer wrote:
> Anyway, point being that PostgreSQL from Macports, Homebrew, and/or
> EnterpriseDB's installer might be present ... and even in use.
Perhaps you should direct those users towards http://postgresapp.com
--
Peter Geoghegan
--
Sent via pg
On 06/12/2013 02:24 PM, Tom Dunstan wrote:
> On 12 June 2013 14:19, Craig Ringer wrote:
>
>> Postgres.app is the source of quite a lot of other pain too, though. One
>> of the bigger problems is that people want/need to link to its libpq
>> from client drivers like Ruby's Pg gem, but almost inevit
On 12 June 2013 14:19, Craig Ringer wrote:
> Postgres.app is the source of quite a lot of other pain too, though. One
> of the bigger problems is that people want/need to link to its libpq
> from client drivers like Ruby's Pg gem, but almost inevitably instead
> link to libpq from Apple's ancient
On 06/12/2013 08:52 AM, Tom Dunstan wrote:
> Hi Josh
>
> On 11 June 2013 04:37, Josh Berkus wrote:
>
>> I don't personally see a reason for plural locations, but it would be
>> nice if it recursed (that is, looked for .so's in subdirectories). My
>> reason for this is that I work on application
Hi Josh
On 11 June 2013 04:37, Josh Berkus wrote:
> I don't personally see a reason for plural locations, but it would be
> nice if it recursed (that is, looked for .so's in subdirectories). My
> reason for this is that I work on applications which have in-house
> extensions as well as public o
>> *I* don't want that at all. All I'd like to have is a postgresql.conf
>> option specifying additional locations.
>
> Same from me. I think I would even take non-plural location.
I don't personally see a reason for plural locations, but it would be
nice if it recursed (that is, looked for .so
Andres Freund writes:
> On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
>> More generally, it seems pretty insane to me to want to configure a
>> "trusted" PG installation so that it can load C code from an untrusted
>> place. The trust level cannot be any higher than the weakest link.
>> Thus, I d
Andres Freund writes:
>> In any case, no packager is going to ship an insecure-by-default
>> configuration, which is what Dimitri seems to be fantasizing would
>> happen. It would have to be local option to relax the permissions
>> on the directory, no matter where it is.
>
> *I* don't want that
On 2013-06-10 10:39:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
> >> More generally, it seems pretty insane to me to want to configure a
> >> "trusted" PG installation so that it can load C code from an untrusted
> >> place. The trust level
On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
> Dimitri Fontaine writes:
> > For sites where they don't have in-house system packagers, it would be
> > very welcome to be able to setup PostgreSQL in a way that allows it to
> > LOAD the extension's binary code (.so, .dll, .dylib) from a non-root
>
Dimitri Fontaine writes:
> For sites where they don't have in-house system packagers, it would be
> very welcome to be able to setup PostgreSQL in a way that allows it to
> LOAD the extension's binary code (.so, .dll, .dylib) from a non-root
> owned place even if you installed it from official pac
Tom Lane writes:
> Andres Freund writes:
>> I don't really care much about Oliver's usecase TBH, but I would very much
>> welcome making it easier for application developers to package part of
>> ther in-database application code as extensions without either requiring
>> a selfcompiled postgres w
Tom,
> Yeah, if the config option were to be superuser-only, the security issue
> would be ameliorated --- not removed entirely, IMO, but at least
> weakened. However, this seems to me to be missing the point, which is
> that the extensions feature is designed to let the DBA have control over
> w
On 5 June 2013 05:58, Andres Freund wrote:
> Yea, I know of Dimitri's work ;). But I really would like this to work
> for C extensions as well. For me personally its no problem at all that
> this wouldn't work on conservatively configured machines. Heck, I
> *don't* want it to work on production
On 2013-06-04 16:24:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't really care much about Oliver's usecase TBH, but I would very much
> > welcome making it easier for application developers to package part of
> > ther in-database application code as extensions without either requiri
On 06/04/2013 09:07 PM, Tom Lane wrote:
It presumably wouldn't be terribly hard for Oliver to patch the sources
to look in something other than SHAREDIR/extension/, but I'm not sure
I see the point of inventing a platform-specific name for that
directory; seems like it would mostly just confuse u
Andres Freund writes:
> I don't really care much about Oliver's usecase TBH, but I would very much
> welcome making it easier for application developers to package part of
> ther in-database application code as extensions without either requiring
> a selfcompiled postgres with a custom extension d
On 2013-06-04 16:07:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The only argument with a good bit of merit I can see is that it could
> > lead to unexpected extensions being loaded if e.g. hstore isn't
> > installed in the normal extension directory but another extension with
> > the sam
Andres Freund writes:
> The only argument with a good bit of merit I can see is that it could
> lead to unexpected extensions being loaded if e.g. hstore isn't
> installed in the normal extension directory but another extension with
> the same name somewhere else.
And just think about the fun you
On 2013-06-04 13:25:10 -0400, Tom Lane wrote:
> Oliver Charles writes:
> > I am working with the NixOS Linux Distribution [nixos], which has a
> > fairly radical approach to package management. If you aren't familiar
> > with it, essentially all packages are installed in isolation - such that
>
Josh Berkus writes:
> On 06/04/2013 10:25 AM, Tom Lane wrote:
>> Basically, none of those are likely to get accepted because of security
>> concerns. We *don't* want this path to be run-time adjustable.
> Really? I don't see a security concern in having a postgresql.conf
> option which requires
On 06/04/2013 10:25 AM, Tom Lane wrote:
>> > What wolud work best for us is to allow this path to be configurable,
>> > ideally through either an environment variable, command line switch, or
>> > (and this is the least desirable) a postgresql.conf option.
> Basically, none of those are likely to
On 06/04/2013 06:25 PM, Tom Lane wrote:
What wolud work best for us is to allow this path to be configurable,
ideally through either an environment variable, command line switch, or
(and this is the least desirable) a postgresql.conf option.
Basically, none of those are likely to get accepted be
Oliver Charles writes:
> I am working with the NixOS Linux Distribution [nixos], which has a
> fairly radical approach to package management. If you aren't familiar
> with it, essentially all packages are installed in isolation - such that
> packages cannot interfere with each other.
Maybe you
Hello
> I am working with the NixOS Linux Distribution [nixos], which has a
> fairly radical approach to package management. If you aren't familiar
> with it, essentially all packages are installed in isolation - such that
> packages cannot interfere with each other.
good.
> This is causing a bi
Hello,
I am working with the NixOS Linux Distribution [nixos], which has a
fairly radical approach to package management. If you aren't familiar
with it, essentially all packages are installed in isolation - such that
packages cannot interfere with each other.
This is causing a bit of a prob
39 matches
Mail list logo
