Re: [HACKERS] TODO list check

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> My last run-through before the apocalypse ...

Actually, I believe the core decided to postpone 7.0 beta to ~ Feb 15
a day or two ago during an IRC chat. Thomas isn't ready, and it seems
like everyone else could use a little more time too. Marc was supposed
to send out a notification to pg-hackers, but I haven't seen it go by...

> * Disallow inherited columns with the same name as new columns

> Either this was just not marked off, or there is some misconception about
> how things should work.

Well, I'm not sure. Clearly, multiple inheritance is a problem if you
can't inherit similar columns from two parents. But is it a good idea
to allow a child to declare (what it thinks is) a new column, and have
that silently get merged with an inherited column? Seems like kicking
out an error would be a better idea.

> * Do not allow bpchar column creation without length

> Looks good to me (and is standard compliant).

I don't see a good reason for this item either.

> * SELECT ... UNION ... ORDER BY fails when sort expr not in result list

> Looks good to me:

No, it's still broken; your test case doesn't actually exercise any
sorting, does it? The bug is that the ORDER BY only gets applied to the
first SELECT; the rest are just appended on. This bug is awaiting
querytree redesign; it's possible that it could be fixed now, but the
UNION code is so bogus that no one really wants to touch it now...

> * SELECT ... UNION ... GROUP BY fails if column types disagree

> Shouldn't it?

Not if they can be promoted to a common supertype. The entry is pretty
misleading because it is so terse though. The system *does* in fact
promote to a common supertype, it's the GROUP BY part that is at risk.
My note about this reads
select q1 from int8_tbl union select f1 from int4_tbl group by f1;
fails (subtly) because wrong sortop is applied to f1.
Examining the parsetree shows that int4lt is applied to sort f1 (for
grouping) *after* it is promoted to int8. Oops. Again, this is
probably very difficult to fix without parsetree restructuring.

> * Allow user to define char1 column

> Both of
> create table test (a char);
> create table test (a char(1));
> seem to work.

The problem is that you can't any longer get at the plain "char"
datatype, which is not to be confused with bpchar(1). If you just want
a one-byte datatype, say for a poor man's enumerated type ('A' =
something, 'B' = something else, etc), you can't have it. bpchar(1)
acts the same but actually occupies 5 to 8 bytes :-(. True "char" is
still used in several system tables, there's just no good way for users
to get at it. I think the proposal was to rename it "char1" so that it
could be accessed.

Come to think of it, it was mostly me complaining about this, so maybe
I should just go do it; no time for it like 7.0, no? Will anyone object
if I do this?

> * Add support for & operator

> To do what?

I don't know what this is about either.

regards, tom lane