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

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Sat, 29 Aug 1998 21:44:12 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Release 6.4
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@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sun, 30 Aug 1998 16:15:15 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Release 6.4
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@{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.

Sun, 30 Aug 1998 19:01:01 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] Release 6.4
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@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sun, 30 Aug 1998 22:00:12 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Release 6.4
>
> 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@debis.com (Jan Wieck) #



Fri, 4 Sep 1998 16:33:17 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Release 6.4


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?



Fri, 04 Sep 1998 11:49:26 -0400
David Hartwig <daveh@insightdist.com>
Re: [HACKERS] Release 6.4
> >
> > 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@candle.pha.pa.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)

Fri, 4 Sep 1998 14:18:36 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Release 6.4
> > 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

Sat, 05 Sep 1998 01:06:10 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Release 6.4