On 5/4/06, Tom Lane [EMAIL PROTECTED] wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Currently, configure ignores unknown --enable/disable/with/without
options.
The autoconf people consider that a feature, not a bug. I'm
disinclined to second-guess the designers of the tool,
On Fri, May 05, 2006 at 02:22:25PM +0300, Marko Kreen wrote:
AFAIK that 'feature' is there to support configuring a 'tree'
of projects (like gcc), where subprojects have their own configure
scripts with different options. That way you can give all options
to top-level configure script which
Done, for Solaris and x86.
---
Robert Lor wrote:
Hi Bruce,
The new SPARC assembly file src/backend/port/tas/solaris_sparc.s uses /
instead of ! for comments, and as a result the compile fails with Sun
Studio 11.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marko Kreen
Sent: 05 May 2006 12:22
To: Tom Lane
Cc: Martijn van Oosterhout; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] [PATCH] Have configure complain about
unknown options
As
I am thinking we would need an option at the start like --strict that
would throw an error for any later invalid options.
---
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
On Fri, May 05, 2006 at 08:34:36AM -0400, Bruce Momjian wrote:
I am thinking we would need an option at the start like --strict that
would throw an error for any later invalid options.
Well, --strict would be tricky, if it's possible. My reading of the
autoconf code doesn't indicate a means
Martijn van Oosterhout wrote:
On Fri, May 05, 2006 at 08:34:36AM -0400, Bruce Momjian wrote:
I am thinking we would need an option at the start like --strict that
would throw an error for any later invalid options.
Well, --strict would be tricky, if it's possible. My reading of the
On Fri, May 05, 2006 at 09:13:54AM -0400, Alvaro Herrera wrote:
Well, --strict would be tricky, if it's possible. My reading of the
autoconf code doesn't indicate a means of doing adding abitrary
options. But something like --enable-strict-options would be fairly
straight forward. Problem
Ühel kenal päeval, N, 2006-05-04 kell 18:21, kirjutas Sven Suursoho:
Hi,
Sun, 30 Apr 2006 19:14:28 +0300, Tom Lane [EMAIL PROTECTED]:
Sven Suursoho [EMAIL PROTECTED] writes:
Unfortunately, there is still one problem when using unpatched python,
caused by too aggressive assert.
Bruce, the change was only needed for the SPARC version only. The x86
file worked just fine before and needs to be reverted back. Yes, they
are different.
Apologies if the message was not clear the first time!
Thanks,
Robert
Bruce Momjian wrote:
Done, for Solaris and x86.
I think that a less confusing way of saying it would be :
Generators crash if python version used is 2.4.x and it is compiled
with asserts.
Currently only known linux distributions to distibute such python.so
files are Fedora and possibly other RedHat distributions, while
Gentoo,
Robert Lor wrote:
Bruce, the change was only needed for the SPARC version only. The x86
file worked just fine before and needs to be reverted back. Yes, they
are different.
OK, fixed, thanks.
Apologies if the message was not clear the first time!
Yes, you were clear, but it was so
I am worried if we change the default behavior that build systems will
fail, but fail after our release when they go to package, and we will
not get feedback until to late.
---
Martijn van Oosterhout wrote:
-- Start of PGP
I've just realized that the locking considerations in this patch are
considerably more complicated than we thought. The discussion so far
considered only half of what the deletion interlock needs to accomplish.
We have to ensure that indexscans don't lose their place, which is
solved in the patch
Bruce Momjian wrote:
Robert Lor wrote:
Bruce, the change was only needed for the SPARC version only. The x86
file worked just fine before and needs to be reverted back. Yes, they
are different.
OK, fixed, thanks.
Apologies if the message was not clear the first time!
Yes, you were clear,
Fri, 05 May 2006 19:20:55 +0300, Joshua D. Drake [EMAIL PROTECTED]:
I think that a less confusing way of saying it would be :
Generators crash if python version used is 2.4.x and it is compiled
with asserts. Currently only known linux distributions to distibute
such python.so
files
I wrote:
BTW, I just realized another bug in the patch: btbulkdelete fails to
guarantee that it visits every page in the index. It was OK for
btvacuumcleanup to ignore pages added to the index after it starts,
but btbulkdelete has to deal with such pages.
Actually, as written this patch does
On Fri, May 05, 2006 at 12:28:48PM -0400, Bruce Momjian wrote:
I am worried if we change the default behavior that build systems will
fail, but fail after our release when they go to package, and we will
not get feedback until to late.
I guess there are a number of ways to deal with this:
Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
On Thu, 4 May 2006, Tom Lane wrote:
Don't try to compile SSL CRL support if local SSL installation hasn't
got it. Per buildfarm failure on 'canary'.
It seems a little bit dangerous to just not check the CRL without so much
as a
Bruce Momjian pgman@candle.pha.pa.us writes:
The attached patch checks for the file, and either user it or generates
a log message that it was skipped.
I still can't get excited about this. Who will it help? The DBA who is
silly enough to think his ancient SSL library supports CRL is probably
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
The attached patch checks for the file, and either user it or generates
a log message that it was skipped.
I still can't get excited about this. Who will it help? The DBA who is
silly enough to think his ancient SSL library
On Fri, 5 May 2006, Tom Lane wrote:
I wrote:
BTW, I just realized another bug in the patch: btbulkdelete fails to
guarantee that it visits every page in the index. It was OK for
btvacuumcleanup to ignore pages added to the index after it starts,
but btbulkdelete has to deal with such pages.
As an example of absurdity of this problem: let's assume there is known
distribution with buggy gethostbyname(). Fact, that we know about this,
shouldn't stop us developing TCP/IP applications. Especially, if there
is also patch for this bug :)
It would be real shame to prevent using
pgman wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
The attached patch checks for the file, and either user it or generates
a log message that it was skipped.
I still can't get excited about this. Who will it help? The DBA who is
silly enough to think his
Heikki Linnakangas [EMAIL PROTECTED] writes:
The first solution that occurs to me is to force page splits to choose the
target page so that it's blkno the original page's blkno during vacuum.
I thought about that too, but don't like it for three reasons:
* it encourages index bloat, the
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Fri, 5 May 2006, Tom Lane wrote:
BTW, I just realized another bug in the patch: btbulkdelete fails to
guarantee that it visits every page in the index.
The first solution that occurs to me is to force page splits to choose the
target page so
Bruce Momjian wrote:
I am now wondering if fe-secure.c, the front-end code, should also check
for root.crl. The attached patch implents it.
Updated patch attached and applied. It adds CRL checking to libpq. It
returns an error if the CRL file exists, but the library can't process
it, just
I am not sure this is of general enough usefulness to be in the backend.
Can you add it as a pgfoundry project?
---
Fabien COELHO wrote:
Dear PostgreSQL developers,
Please find attached a small patch to convert bytea
As Tom asked, why not use seqname.last_value? Looking at your output:
+ if (showSeq !showTables)
+ appendPQExpBuffer(buf,
+ ,\n curval(c.oid) as \%s\
+ ,\n CASE curvalcheck(c.oid) WHEN '1' THEN '%s'
WHEN '0' THEN
Bruce Momjian wrote:
What fields do we want to show? Maybe the TODO item is not needed. Is
this all we want to show?
IRC what we want is something like this.
regression=# \d abc
Sequence public.abc
Column| Type
--+-
sequence_name | abc
last_value| 1
I am thinking we just add another column to the \d display for sequences
showing the current value.
---
Euler Taveira de Oliveira wrote:
Bruce Momjian wrote:
What fields do we want to show? Maybe the TODO item is not
On 4/30/06, Jaime Casanova [EMAIL PROTECTED] wrote:
On 4/29/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
there is a chance to add a STEP clause to the FOR statement in plpgsql?
This is not free: it'd require making STEP a
32 matches
Mail list logo
