Re: [HACKERS] 6.5 TODO list
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] 6.5 TODO list |
Дата | |
Msg-id | 9286.926372941@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 6.5 TODO list (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] 6.5 TODO list
|
Список | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.us> writes: > OK, here is the list. Please send me changes. > Can not insert/update oid I think this is very unlikely to get fixed for 6.5, might as well just put it on the to-do-later list. > EXPLAIN SELECT 1 UNION SELECT 2 crashes, rewrite system? Already fixed, I believe, unless someone can produce a case that fails... > move UNION stuff into rewrite files Is this the same as EXPLAIN issue above, or a different concern? > Vacuum of tables >2 gigs - NOTICE: Can't truncate multi-segments relation This is definitely a "must fix" item for 6.5, IMHO... > missing optimizer selectivities for date, etc. The selectivity-estimation code needs major work. Again, I'd say just shove it to the 6.6 list... > int8 indexing needs work? Is this done, or are there still problems? > hash on int2/char only looks a first bytes, and big-endian machines hash poorly Fixed. > Some CASE() statements involving two tables crash Fixed. > CREATE FUNCTION fails Isn't this fixed? I wasn't aware of any remaining problems... > Make sure pg_internal.init generation can't cause unreliability > ... > pg_interal.init, check for reliability on rebuild Duplicate items, I think. > GROUP BY expression? I think I've fixed the problems here. > problem with ALTER TABLE on inherited > ... > ALTER TABLE ADD COLUMN to inherited table put column in wrong place Duplicates? > GROUP BY can reference columns not in target list What's wrong with that? > SELECT name, value FROM t1 as touter WHERE (value/(SELECT AVG(value) > FROM t1 WHERE name = touter.name)) > 0.75; fails Fixed. regards, tom lane
В списке pgsql-hackers по дате отправления: