This one makes it mandatory to pick some kind of
authentication. If
that's not wanted, it's easy to change it to default to
trust (which
I think is wrong, but we've been through that already..)
I don't think I like any of this. Sooner rather than later, people
need to look
Magnus, why is this reassignment needed, basically the 'else' part:
! ifeq ($(PORTNAME), win32)
! xperl_archlibexp=$(subst \,/,$(perl_archlibexp))
! xperl_privlibexp=$(subst \,/,$(perl_privlibexp))
! perl_embed_ldflags=-L $(xperl_archlibexp)/CORE -lperl58
! else
!
Magnus, why is this reassignment needed, basically the 'else' part:
! ifeq ($(PORTNAME), win32)
! xperl_archlibexp=$(subst \,/,$(perl_archlibexp))
! xperl_privlibexp=$(subst \,/,$(perl_privlibexp))
! perl_embed_ldflags=-L $(xperl_archlibexp)/CORE -lperl58
! else
!
Magnus Hagander [EMAIL PROTECTED] writes:
I originally tried the approach with
ifeq ($(PORTNAME),win32)
perl_archlibexp=$(subst, \,/,$(perl_archlibexp))
...
but then make complained about recursive assignment of the variable. If
there is a simple way to get around that, it wouldn't be
Here's a version of this patch that includes documentation updates.
//Magnus
-Original Message-
From: Magnus Hagander
Sent: den 15 juli 2004 23:02
To: [EMAIL PROTECTED]
Subject: [PATCHES] initdb authentication
Ok, here is one more try at the initdb default authentication stuff.
This
On Mon, 12 Jul 2004, Klaus Naumann wrote:
Hi,
I've sent this patch a while ago - was it applied? Is something not ok
with it? Don't want to bug anyone - just would like to have some feedback.
Grettings, Klaus
On Mon, 12 Jul 2004, Klaus Naumann wrote:
Hi,
sorry, the last patch is buggy
Matthew, were are we on this patch?
---
Matthew T. O'Connor wrote:
FYI, I am out of town from Friday 7/2 till Monday evening 7/5. I
probably won't have email while I'm gone. I will continue working on
this when I get
Attached is the modified patch I applied. Thanks.
---
Magnus Hagander wrote:
Here is a patch required to build plperl with win32. The issues were:
* perl_useshrplib gets set to yes and not to true. I assume it's set
I think it's ready to apply barring any feedback to the contrary.
Actually I do have a small improvement I will send in tomorrow (sorry
can't do it any sooner) that defaulted autovac_enabled to false, and makes
autovac fail more gracefully when the stats system is not enabled, but
that shouldn't
Matthew T. O'Connor wrote:
I think it's ready to apply barring any feedback to the contrary.
Actually I do have a small improvement I will send in tomorrow (sorry
can't do it any sooner) that defaulted autovac_enabled to false, and makes
autovac fail more gracefully when the stats system is
Matthew T. O'Connor wrote:
I think it's ready to apply barring any feedback to the contrary.
Actually I do have a small improvement I will send in tomorrow (sorry
can't do it any sooner) that defaulted autovac_enabled to false, and
makes autovac fail more gracefully when the stats system is
I got a new idea on this. I think we should add an initdb option that
takes a string to specify the local authentication method:
initdb --localauth 'ident'
or whatever the user wants. I think this is more flexible and more
compact. It would default to 'trust', and the packagers could
On Fri, 2004-07-16 at 17:13, Bruce Momjian wrote:
Peter Eisentraut wrote:
A nitpick on that parameter name: There is not reason to abbreviate
autovacuum: there is enough space. And the _enabled is redundant.
Agreed. Nitpicks are important too because it makes us so beautiful. :-)
:-)
13 matches
Mail list logo
