Thomas Holmgren wrote:
>
> Hello everyone! :)
>
> This little problem is bothering me a lot! It seems that PostgreSQL 7.0
> uses different semantics than Oracle when evaluting SQL?!
Not that much, but ...
> [...]
>
> I have defined two views, viewA and viewB. They are defined as follow:
>
> CREATE VIEW viewA AS SELECT number, sum(amount) AS amount
> FROM A GROUP BY number;
>
> CREATE VIEW viewB AS SELECT number, sum(amount) AS amount
> FROM B FROUP BY number;
here the problems start. PostgreSQL has (since epoch)
problems with aggregates, GROUP BY clauses and some other
things when used in views. We know exactly what causes these
problems, but fixing them requires some huge changes across
the entire backend. This work is scheduled for the 7.2
release.
> BUT WHEN I'm doing the EXACT SAME THING in PostgreSQL 7.0 I get a
> different result! It seems that Postgres executes the natural join in the
> query BEFORE performing the sum() in the definition of the views thus
> giving me a wrong result.
Close, due to the fact that after applying the rewrite rules
for the views, the entire thing is one join, but with only
one (and thus wrong) gouping step on the toplevel. The
groupings must be done on deeper levels per view, but theres
no way to tell that in the querytree from the rewriter.
> How can I fix that??
> How come PostgreSQL uses different semantics when evaluating SQL
> expressions than other BDMSs?
You can help us doing the huge changes in a couple of months.
Even if you cannot help coding it, you might penetrate what
we do with all those complicated schemas.
Stay tuned.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
