Re: [HACKERS] 6.5 TODO list

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] 6.5 TODO list
Date: 1999-05-10 22:01:18
Message-ID: 199905102201.SAA15406@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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.

Moved.

>
> > EXPLAIN SELECT 1 UNION SELECT 2 crashes, rewrite system?
>
> Already fixed, I believe, unless someone can produce a case that
> fails...

Good. Thanks.

>
> > move UNION stuff into rewrite files
>
> Is this the same as EXPLAIN issue above, or a different concern?

That is for me. I currently do UNION in postgres.c, shoud perhaps move
to rewrite system. Not sure yet.

>
> > Vacuum of tables >2 gigs - NOTICE: Can't truncate multi-segments relation
>
> This is definitely a "must fix" item for 6.5, IMHO...

Yes. It shows we are getting bigger. Most/all? of my commerical
database clients don't have 2-gig tables.

>
> > 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...

Moved.

>
> > int8 indexing needs work?
>
> Is this done, or are there still problems?

Not sure. Just asking. I saw Thomas complaining about some testing
problems. Let's what he says.

>
> > hash on int2/char only looks a first bytes, and big-endian machines hash poorly
>
> Fixed.

Removed.

> > Some CASE() statements involving two tables crash
>
> Fixed.

Good.

> > CREATE FUNCTION fails
>
> Isn't this fixed? I wasn't aware of any remaining problems...

OK.

>
> > Make sure pg_internal.init generation can't cause unreliability
> > ...
> > pg_interal.init, check for reliability on rebuild
>
> Duplicate items, I think.

Yes.

>
> > GROUP BY expression?
>
> I think I've fixed the problems here.

Removed.

>
> > problem with ALTER TABLE on inherited
> > ...
> > ALTER TABLE ADD COLUMN to inherited table put column in wrong place
>
> Duplicates?

Yes.

> > GROUP BY can reference columns not in target list
>
> What's wrong with that?

Is that not a problem. What possible use would GROUP BY on columns not
in target list be of use. Maybe it is. I remember someone asking for
something like this. I will remove the item unless someone complains.
I thought you were the one complaining about it.

>
> > SELECT name, value FROM t1 as touter WHERE (value/(SELECT AVG(value)
> > FROM t1 WHERE name = touter.name)) > 0.75; fails
>
> Fixed.

Already removed.

Thanks for the updates.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-05-10 22:02:06 New 6.5 Open Items list
Previous Message Tom Lane 1999-05-10 21:55:23 Re: [HACKERS] Re: [SQL] plpgsql error