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.
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
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Patch attached (surprinsingly small), though it only applies with the
savepoint patch applied(*). If any driver writer wants to play, however,
it's easy to see what's going on -- a ParameterStatus message will be
received from the backend
Peter Eisentraut wrote:
> 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 g
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 i
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 s
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'
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
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 bugg
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
"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
>
>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
>! xperl_archlibexp=$(perl
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
! xperl_archlibexp=$(perl_archlibx
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Patch attached (surprinsingly small), though it only applies with the
> savepoint patch applied(*). If any driver writer wants to play, however,
> it's easy to see what's going on -- a ParameterStatus message will be
> received from the backend whenever
OK,
Here is another patch that fixes a stack of pg_dump bugs:
* Fix help text ordering
* Add back --set-session-authorization to pg_dumpall. Updated the docs
for that. Updated help for that.
* Dump ALTER USER commands for the cluster owner ("pgsql"). These are
dumped AFTER the create user and
> > > 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
>
Hackers,
I tried to implement the reporting of the current transaction level to
the client using an ad-hoc ParameterStatus message. Seems it works.
To see it working I added a %d escape to psql prompt processing:
alvherre=# \set PROMPT1 '[EMAIL PROTECTED]/%R[%d]%x '
[EMAIL PROTECTED] begin;
BEGI
18 matches
Mail list logo
