Jan Wieck wrote:
> >
> > On Sat, 29 Aug 1998, Bruce Momjian wrote:
> >
> > > As far as I am concerned, we are ready to go.
> >
> > I've already started up the nightly snapshots for
> > debugging...anyone else has any "new features" they want to slide in
> > before the BETA freeze, they have until tomorrow (Monday)...after that,
> > its purely a bug fix period.
> >
> > First v6.4beta1 to be put out on Friday, final release to be put
> > out on October 1st...
> >
> > Marc G. Fournier
>
> Back from a training this week.
>
> I had really trouble on the attempt to fix more things in the
> rewrite system. Thus I decided to give a new rewrite handler
> a try and up to now I got the view rewrite stuff working (can
> handle most cases of RIR rules including aggregate columns
> that are rewritten into subselects when used in the
> qualification). Must now adapt the insert/update/delete stuff
> into it.
>
> What's the target for 6.4 release?
>
> Another question on aggregate columns:
>
> I can define a view
>
> CREATE VIEW v1 AS
>
> But it's impossible to omit the group by and another side
> effect is that it would never return any row where count(y.a)
> would be zero.
>
> Is that the correct behaviour? What does standard say?
>
I believe it is correct. I have never seen any statements or documents to
the contrary. Every item in the target list must be either an aggregate
function, matched with a GROUP BY item, or a literal. I'm not sure if we
support the literal.
I am a little confused by the counting zero rows issue.
SELECT count(*) FROM foo -- zero is possible
SELECT bar, count(*) FROM foo GROUP BY bar
Zero counts are impossible in this trivial case because you cannot know what
tuples are missing.
In your example:
SELECT x.a, x.b, count(y.a) FROM t1 x, t2 y
WHERE x.a = y.a GROUP BY x.a, x.b;
Are you suggesting that if there are rows in t1 that are not in t2, that the
count could/should be zero?
