Here is the list.  Folks, if we are going to release in 13 days, we will
need to reduce the size of this list.  I started moving some of the
major items to the TODO list, but many are easy fixes that really should
be done by 6.5.

---------------------------------------------------------------------------

Default of '' causes crash in some cases
shift/reduce conflict in grammar, SELECT ... FOR [UPDATE|CURSOR]
SELECT 1; SELECT 2 fails when sent not via psql, semicolon problem
SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error
Table with an element of type inet, will show "0.0.0.0/0" as "00/0"
When creating a table with either type inet or type cidr as a primary,unique
   key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equal
Allow "col AS name" to use name in WHERE clause?  Is this ANSI? 
	Works in GROUP BY
Make sure pg_internal.init concurrent generation can't cause unreliability
SELECT ... WHERE col ~ '(foo|bar)' works, but CHECK on table always fails
ALTER TABLE ADD COLUMN to inherited table put column in wrong place
resno's, sublevelsup corrupt when reaching rewrite system
crypt_loadpwdfile() is mixing and (mis)matching memory allocation
  protocols, trying to use pfree() to release pwd_cache vector from realloc()
3 = sum(x) in rewrite system is a problem
Fix function pointer calls to take Datum args for char and int2 args(ecgs)

Do we want pg_dump -z to be the default?
pg_dump of groups fails
pg_dump -o -D does not work, and can not work currently, generate error?
psql \d should show precision
dumping out sequences should not be counted in pg_dump display

Make psql \help, man pages, and sgml reflect changes in grammar
Markup sql.sgml, Stefan's intro to SQL
Markup cvs.sgml, cvs and cvsup howto
Add figures to sql.sgml and arch-dev.sgml, both from Stefan
Include Jose's date/time history in User's Guide (neat!)
Generate Admin, User, Programmer hardcopy postscript

Future TODO items
-----------------
Make Serial its own type
Add support for & operator
store binary-compatible type information in the system somewhere 
add ability to add comments to system tables using table/colname combination
process const=const parts of OR clause in separate pass
make oid use oidin/oidout not int4in/int4out in pg_type.h, make oid use
	unsigned int more reliably, pg_atoi()
CREATE VIEW ignores DISTINCT
Move LIKE index optimization handling to the optimizer?
Allow ESCAPE '\' at the end of LIKE for ANSI compliance, or rewrite the
	LIKE handling by rewriting the user string with the supplied ESCAPE
Fix leak for expressions?, aggregates?
Improve LIMIT processing by using index to limit rows processed
CLUSTER failure if vacuum has not been performed in a while
CREATE OPERATOR *= (leftarg=_varchar, rightarg=varchar, 
	procedure=array_varchareq); fails, varchar is reserved word, quotes work
Improve Subplan list handling
Allow Subplans to use efficient joins(hash, merge) with upper variable
Update reltuples from COPY command
CREATE INDEX zman_index ON test (date_trunc( 'day', zman ) datetime_ops) fails
	index can't store constant parameters, allow SQL function indexes?
Improve NULL parameter passing into functions


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 18 May 1999 13:45:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Open 6.5 items
> SELECT ... WHERE col ~ '(foo|bar)' works, but CHECK on table always fails

Does not reproduce here.

test=> create table t2 (i text check(i ~ '(foo|bar)'));
CREATE
test=> insert into t1 values ('aaa');
ERROR:  ExecAppend: rejected due to CHECK constraint t1_i
test=> insert into t1 values ('foo');
INSERT 18634 1
---
Tatsuo Ishii

Wed, 19 May 1999 21:06:56 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Open 6.5 items 
> > SELECT ... WHERE col ~ '(foo|bar)' works, but CHECK on table always fails
> 
> Does not reproduce here.
> 
> test=> create table t2 (i text check(i ~ '(foo|bar)'));
> CREATE
> test=> insert into t1 values ('aaa');
> ERROR:  ExecAppend: rejected due to CHECK constraint t1_i
> test=> insert into t1 values ('foo');
> INSERT 18634 1

Thanks.  Removed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 19 May 1999 12:24:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
> resno's, sublevelsup corrupt when reaching rewrite system

    Don't  remember  exactly  how  I produced them.  Haven't seen
    them again after the latest changes in the  rule  system.   I
    think  it  was due to incorrect handling of unrewritten TLE's
    from group by clauses, which are now pulled out of  the  main
    targetlist.

> 3 = sum(x) in rewrite system is a problem

    Is  it?  I guess what is meant by this item is the problem of
    the  rewriter  that  it  must  create  subqueries  for   view
    aggregate columns if they appear in the WHERE clause.

    That  entire  area is a very problematic one. And for sake it
    must wait for after v6.5. Aggregates and GROUP  BY  in  views
    are  unsafe  and  depend  on  the  later  usage  of the view.
    Consider the following:

        CREATE TABLE t1 (a text, b text, c int4);
        CREATE VIEW v1 AS SELECT a, b, sum(c) as n
          FROM t1 GROUP BY a, b;
        CREATE TABLE t2 (a text, b text);

        SELECT t2.a, v1.n FROM t2, v1 WHERE t2.a = v1.a
          GROUP BY t2.a;

    Due to the new code in the rewriter, adding  junk  TLE's  for
    the  view's  GROUP BY columns, this doesn't crash the backend
    anymore.  The result (IMHO wrong) will return  multiple  rows
    with same t2.a because the rewritten query reads as:

        SELECT t2.a, sum(t1.c) FROM t2, t1
          WHERE t2.a = t1.a GROUP BY t2.a, t1.a, t1.b;

    The correct result would be only one row per t2.a with one of
    the possible values of v1.n if a plain SELECT *  FROM  v1  is
    done.   But  there's  currently  no  way to express that in a
    querytree.

    What's absolutely broken is:

        SELECT t2.a, sum(v1.n) FROM t2, v1 WHERE t2.a = v1.a
          GROUP BY t2.a;

    This  gives  totally  unpredictable  results  because   after
    rewriting  you  have  cascaded aggregates. And I expected the
    rotten results I've seen from it :-)

    I really hope to find the time after  v6.5  to  implement  my
    idea  of subselecting RTE's where I can place all those views
    that have these beasty DISTINCT, UNION, GROUP  BY  and  other
    f*ing  stuff. The result of a subselecting RTE will be an on-
    the-fly-materialization of the entire view used in a nestloop
    or so (dunno exactly yet). It's expansive - yes - and I don't
    know yet how to pull out restrictions from the  WHERE  clause
    to  make  the  views subset as small as possible - but AFAICS
    the only fail-safe way to  meet  the  view  definition  in  a
    complex join.

> Future TODO items
> -----------------
> CREATE VIEW ignores DISTINCT

    Covered above.


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) #



Wed, 19 May 1999 19:29:40 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Open 6.5 items
> > resno's, sublevelsup corrupt when reaching rewrite system
> 
>     Don't  remember  exactly  how  I produced them.  Haven't seen
>     them again after the latest changes in the  rule  system.   I
>     think  it  was due to incorrect handling of unrewritten TLE's
>     from group by clauses, which are now pulled out of  the  main
>     targetlist.

Removed.  I suspected you had fixed it with your last GROUP patch,
because you were addressing this exact area.

> 
> > 3 = sum(x) in rewrite system is a problem
> 
>     Is  it?  I guess what is meant by this item is the problem of
>     the  rewriter  that  it  must  create  subqueries  for   view
>     aggregate columns if they appear in the WHERE clause.

The issue where was that aggregates can't be on the right in some cases.
Tom Lane brought this up.


> 
>     That  entire  area is a very problematic one. And for sake it
>     must wait for after v6.5. Aggregates and GROUP  BY  in  views
>     are  unsafe  and  depend  on  the  later  usage  of the view.
>     Consider the following:

Yes, I understand.

> > Future TODO items
> > -----------------
> > CREATE VIEW ignores DISTINCT
> 
>     Covered above.
> 

OK.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 19 May 1999 14:30:01 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
> shift/reduce conflict in grammar, SELECT ... FOR [UPDATE|CURSOR]

    Fixed.

    The  problem  was  that  CursorStmt tried to parse FOR UPDATE
    which is already parsed by SelectStmt.

    To fix it I had to add FOR READ ONLY to SelectStmt (returning
    NULL  for  forUpdate  as if empty) and let CursorStmt look at
    there for the elog(). Don't know if FOR READ ONLY is O.K. for
    regular  SELECT queries too, but I think it's better to allow
    this than to remove this syntax from CURSOR.

    The same error is still in the ecpg parser. AFAICS fixing  it
    the  same  way  there  would make ecpg accept the DECLARE/FOR
    UPDATE syntax because there is no Query where to  look  at  a
    forUpdate. Any suggestions?


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) #



Thu, 20 May 1999 15:05:49 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Open 6.5 items