On 5/4/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Martijn van Oosterhout 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, especially
with a pat
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 whic
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
> -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
>
>
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:[E
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
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. P
Ü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 aggress
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, Ubun
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 illo
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 s
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 d
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 mu
Bruce Momjian 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
also silly enough no
Tom Lane wrote:
> Bruce Momjian 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 p
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 gener
pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 SS
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
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, j
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 byt
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
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
incr
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 n
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
Dear Bruce,
I am not sure this is of general enough usefulness to be in the backend.
Hmm...
I think that the inability to convert nearly binary compatible standard
types one to the other is a postgresql issue. Even if it is not often
useful, the point is completeness and soundness of the t
33 matches
Mail list logo
