Thread
-
Open 6.5 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-18T17:45:27Z
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
-
Re: [HACKERS] Open 6.5 items
Jan Wieck <jwieck@debis.com> — 1999-05-19T17:29:40Z
> 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) # -
Re: [HACKERS] Open 6.5 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-19T18:30:01Z
> > 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
-
Re: [HACKERS] Open 6.5 items
Jan Wieck <jwieck@debis.com> — 1999-05-20T13:05:49Z
> 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) #