Thread: Open 6.5 items
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 vectorfrom 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 useunsigned 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 theLIKE handling by rewriting the user string with thesupplied 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, quoteswork 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) failsindex can't store constant parameters, allowSQL 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, Pennsylvania19026
> 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
> > 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,
Pennsylvania19026
> 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) #
> > 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, Pennsylvania19026
> 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) #