Re: [HACKERS] Release 6.4

As far as I am concerned, we are ready to go.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)

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
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

Thus spake The Hermit Hacker
> 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.

I'll make one last appeal for a field in pg_class to list the primary
key. Really, we throw this information away and we shouldn't.

I have a pile of helper functions for PyGreSQL that I can't distribute
because I don't have a clean way of getting the key. Being able to grab
this information from the schema would be really useful. As it happens
I am getting ready to package up the next release right now so the
timing is perfect.

--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

On Sun, 30 Aug 1998, D'Arcy J.M. Cain wrote:

> Thus spake The Hermit Hacker
> > 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.
>
> I'll make one last appeal for a field in pg_class to list the primary
> key. Really, we throw this information away and we shouldn't.

Sounds reasonable to me..anyone able to do a patch up for this
quickly, though?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

>
> 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 SELECT x.a, x.b, count(y.a)
FROM t1 x, t2 y WHERE x.a = y.a GROUP BY x.a, x.b;

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?

The zero counting rows could also show up and the group by
clause can be optional if we create a new type of func node
that contains a parsetree instead of a reference to the
pg_proc entry. The rewrite handler could build them and I
know how. And it would enhance the view capabilities
extremely since using that technique a qualification could
compare two aggregate columns of a view. This is still
missing in the new rewrite handler because the planner cannot
handle sublinks with an aggregate in the lefthand.

Can we agree that this is still bug fixing instead of new
feature? How much time would I have to make it working?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

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?

> >
> > 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 SELECT x.a, x.b, count(y.a)
> FROM t1 x, t2 y WHERE x.a = y.a GROUP BY x.a, x.b;
>
> 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?
>
> The zero counting rows could also show up and the group by
> clause can be optional if we create a new type of func node
> that contains a parsetree instead of a reference to the
> pg_proc entry. The rewrite handler could build them and I
> know how. And it would enhance the view capabilities
> extremely since using that technique a qualification could
> compare two aggregate columns of a view. This is still
> missing in the new rewrite handler because the planner cannot
> handle sublinks with an aggregate in the lefthand.
>
> Can we agree that this is still bug fixing instead of new
> feature? How much time would I have to make it working?

OK, Jan, keep going. We still have one big bug to fix, and are going to
try to get another item completed. I would say you have a good 7-10
days to keep adding stuff.

The fact that your rewrite fixes MANY long-standing bugs in the view
system means you can contininue adding things in that area well into the
beta period.

Not sure what the cut-off would be because we need to get to a point
where no more bugs are being reported, but we clearly are a long ways
from that right now.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)

> > Can we agree that this is still bug fixing instead of new
> > feature? How much time would I have to make it working?
>
> OK, Jan, keep going. We still have one big bug to fix, and are going
> to try to get another item completed. I would say you have a good
> 7-10 days to keep adding stuff.

Also Jan, if you find that you need more time to work, we can make the
rewritten rewrite the centerpiece of v6.5. So you can decide over the
next week which you would prefer...

Good luck!

- Tom