I thought we'd extracted all the interesting juice from the NIST tests
a couple years ago. Specifically I recall this fix came out of NIST
testing done by Red Hat:
2003-06-06 11:04 tgl
Implement outer-level
aggregates to conform to the SQL spec, with extensions to support
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I thought we'd extracted all the interesting juice from the NIST tests
>> a couple years ago.
> I was just chatting with Neil C on IRC and he mentioned that back when
> they were using it at RedHat, PostgreSQL didn't have schemas so most
> s
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Are we able to run more NIST tests now?
> http://www.itl.nist.gov/div897/ctg/sql_form.htm
I thought we'd extracted all the interesting juice from the NIST tests
a couple years ago. Specifically I recall this fix came out of NIST
testing done b
Are we able to run more NIST tests now?
http://www.itl.nist.gov/div897/ctg/sql_form.htm
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Only for very small values of "current" ...
Argh! Forgot it was a 7.4 server :) Oops.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Wednesday, March 09, 2005 8:45 PM
To: Christopher Kings-Lynne
Cc: Kevin Brown; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] We are not following the spec for HAVING without
GROUP
Christ
Greg Stark <[EMAIL PROTECTED]> writes:
> It sort of seems like "select aggregate(col) from tab" with no GROUP BY clause
> is a bit of a special case. The consistent thing to do would be to return no
> records.
I don't think so. SQL99 defines this stuff in a way that might make you
feel better: it
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> The current _pg_keypositions function generates the numbers from 1 to 32
> using a massive union,
Only for very small values of "current" ...
regards, tom lane
---(end of broadcast)
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>>> Comments? Can anyone confirm whether DB2 or other databases allow
>>> ungrouped column references with HAVING?
> MySQL allows it:
A slightly tighter experiment shows that they treat HAVING like WHERE
in this case:
mysql> create table tab(c
On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
However it would be easy to modify pgpool to allow automatic switch
back (with a risk of unwanted repeating switching, of course). Is
this what you want?
No, your arguments are important. I don't want too much intelligence, but
when I restart primary backend
> On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
>
> >> I'm experimenting with pgpool 2.51 on my Linux box runnung
> >> two postgresql backends: pg74:5432 and pg801:5433
> >>
> >> I configured pgpool to use pg74:5432 as primary backend and
> >> pg801:5433 as second one. Pgpool is running on default port
On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I configured my we
The current _pg_keypositions function generates the numbers from 1 to 32
using a massive union, shouldn't it just use generate_series instead (to
make it faster/simpler)?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free spac
Comments? Can anyone confirm whether DB2 or other databases allow
ungrouped column references with HAVING?
Oracle does not allow such references. It issues "ORA-00979: not a
GROUP BY expression" when you try to hand it such a reference.
MS SQL Server does not allow such references either, yieldin
Kevin Brown <[EMAIL PROTECTED]> writes:
> Hence, it makes sense to go ahead and run the query, but issue a
> warning at the very beginning, e.g. "WARNING: query JOINs tables of tables> without otherwise referencing or making use of those
> tables. This may cause excessively poor performance of
Nicolai Tufar wrote:
> Dear all,
> After struggling for one week to to integrate FreeBSD's vfprintf.c into
> PostgreSQL I finally gave up. It is too dependent on underlying
> FreeBSD system functions. To incorporate it into PostgreSQL we need
> to move vfprintf.c file itself, two dozen files form g
Tom Lane <[EMAIL PROTECTED]> writes:
> In particular this whole business of "moving HAVING into WHERE" is
> wrong and should go away.
It sort of seems like "select aggregate(col) from tab" with no GROUP BY clause
is a bit of a special case. The consistent thing to do would be to return no
record
Tom Lane wrote:
> What that means is that neither the HAVING clause nor the targetlist
> can use any ungrouped columns except within aggregate calls; that is,
>
> select col from tab having 2>1
>
> is in fact illegal per SQL spec, because col isn't a grouping column
> (there are no grouping
On Mar 9, 2005, at 7:25 PM, Tatsuo Ishii wrote:
That's an intended behavior. Or at least a side effect of failover
design. If we allow unlimited switching between the master and the
secondary, pgpool could repeat switching forever if we have unliable
network or hardware.
I didn't really think of it
I wrote in reference to bug#1528:
> What the spec actually says, or at least implies, is that a HAVING
> clause is to be evaluated only once per group --- where the "group"
> is the whole table if there's no GROUP BY clause.
In fact, reading the spec more closely, it is clear that the presence
of
I encounter the similar problem in "make check" (win2k-mingw, 8.0.1). The
regression test could randomly fail due to "could not write block (Invalid
argument)" problem or could not "remove file" problem.
Regards,
Qingqing
p.s. I believe this could be a potential serious problem, so I forward it t
> I'm experimenting with pgpool 2.51 on my Linux box runnung
> two postgresql backends: pg74:5432 and pg801:5433
>
> I configured pgpool to use pg74:5432 as primary backend and
> pg801:5433 as second one. Pgpool is running on default port () and
> I configured my web application to use it, so
Neil Conway wrote:
> Simon Riggs wrote:
> >Oleg is saying that the optimizer doesn't protect against foolish SQL
> >requests. His query is an example of a foolishly written query.
>
> IMHO calling this a "foolishly written query" is completely arbitrary. I
> can imagine plenty of applications for
I wrote:
> I think the problem can be expressed as
> regression=# select 2 as id, max(b) from t2 having 2 = 1;
> id | max
> +-
> 2 |
> (1 row)
> the issue is clearly that the known-false HAVING clause is pushed down
> inside the aggregation, as though it were WHERE. The existing
Tom Lane wrote:
Why is PL/Java dependent on the internal representation of any
particular datatype? Seems like this is a symptom of bad PL design
more than anything else.
I didn't see any other way of doing it short of using string
conversions. That doesn't seem very optimal. Java's internal
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> A user download a pre-built PostgreSQL 7.4.7 from somewhere and a
> pre-built pljava distro from gborg. He gets everything running but
> suddenly encounteres problems with the timetz type. PL/Java apparently
> return the time as zero. The problem is
Scenario:
A user download a pre-built PostgreSQL 7.4.7 from somewhere and a
pre-built pljava distro from gborg. He gets everything running but
suddenly encounteres problems with the timetz type. PL/Java apparently
return the time as zero. The problem is caused by the postgresql binary
being bui
Oleg Bartunov wrote:
On Wed, 9 Mar 2005, Jeff Hoffmann wrote:
Oleg Bartunov wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on
Simon, Neil, all:
> IMHO calling this a "foolishly written query" is completely arbitrary. I
> can imagine plenty of applications for which a cartesian join makes
> sense. In this case the user didn't write the query they meant to write
> -- but it is surely hopeless to prevent that in the general
On Wed, 9 Mar 2005, Jeff Hoffmann wrote:
Oleg Bartunov wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and pg801:5433 as
second one. Pgpool is running on default port ()
Oleg Bartunov wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and pg801:5433
as second one. Pgpool is running on default port () and
I configured my web application to us
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I configured my web application to use it, so I could star
Ühel kenal päeval (teisipäev, 8. märts 2005, 00:52+0100), kirjutas
Gaetano Mendola:
> Hi all,
> running a 7.4.5 it happen to me with another table
> where a single vacuum full was not freeing enough pages,
> here the verbose vacuum full, as you can see only at
> the end: truncated 8504 to 621 page
Neil Conway <[EMAIL PROTECTED]> writes:
> In any case, when this problem does occur, it is obvious to the user that
> something is wrong, and no harm is done.
I don't see why you say that. The whole complaint here is that it's *not*
obvious something is wrong and there *is* damage until it's re
>From what I recall from the conversation, I would say rename the vsprintf
and the sprintf functions in postgres to pq_vsnprintf and pq_snprintf.
Define a couple macros: (in some common header, pqprintf.h?)
#define snprintf pq_snprintf
#define vsnprintf pq_snprintf
Then just maintain the postgres
Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.
We've seen that happen man
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Do you have a way to revert to the old installation to check whether
> the checks fail again? It might be useful to track down exactly
> what happened. It seems wrong that a currently-installed version
> should have adverse effects on a just-built versio
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa and a half
a dozen __XXtoa
On Wed, 9 Mar 2005, Simon Riggs wrote:
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
I have no problem with that ! I just wanted to take a not
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
On Wed, 2005-03-09 at 22:38 +1100, Neil Conway wrote:
> Simon Riggs wrote:
> > Oleg is saying t
Simon Riggs wrote:
Oleg is saying that the optimizer doesn't protect against foolish SQL
requests. His query is an example of a foolishly written query.
IMHO calling this a "foolishly written query" is completely arbitrary. I
can imagine plenty of applications for which a cartesian join makes
sen
On Wed, 2005-03-09 at 11:02 +1100, Neil Conway wrote:
> Oleg Bartunov wrote:
> > I just noticed a little optimizer problem - in second query there is
> > unused 'tycho t2' table alias which gets backend buried.
>
> It's not an "unused table alias", it is specifying the cartesian product
> of `tyc
On Tue, 2005-03-08 at 15:30 +0200, Ioannis Theoharis wrote:
>
> let me, i have turned enable_seqscan to off, in order to discourage
> optimizer to choose seq_scan whenever an idex_scan can be used.
>
> But in this case, why optimizer don't chooses seq_scan (discourage is
> different than prevent)
On Mon, Mar 07, 2005 at 11:53:59PM +, Simon Riggs wrote:
> On Mon, 2005-03-07 at 09:39 -0500, Tom Lane wrote:
> > "Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
[skipped]
> Well, we're using the CRC in 3 separate places...
> (1) for xlog records
> (2) for complete blocks copied to xlog
> (3)
On Wed, Mar 09, 2005 at 03:43:38PM +0800, Christopher Kings-Lynne wrote:
> Hrm, I just did a gmake install; gmake installcheck - that worked fine.
> Then I did gmake check again and now that works fine...
>
> It must have been picking up something from my previously installed pgsql.
Do you hav
Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.
No :)
-
46 matches
Mail list logo
