Re: [HACKERS] TODO list check

On 2000-01-27, Tom Lane mentioned:

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

Okay, now it gives an error if you try to create a new column with the
same name as an inherited column, but allows merging of columns between
inherited tables. Check.

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

How about adding this into TODO.detail, so two months from now everyone
(except those that keep outside lists) remembers it. (Or just rephrase
this item, if you can.)


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

This item may be the same as the one below. The other day while working on
psql and mapping internal to sql types for \d output I noticed that system
tables have char columns with -1 typmod. I suppose that this would be your
char1 type?

> > * Allow user to define char1 column

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

At least the above behaviour is very subtle indeed. While I'm not so
excited about having all kinds of "more efficient" types around for
internal use (char1, abstime, some of the oid arrays), do what you feel is
best. The clean solution would seem to be item

* Allow char() not to use variable-sized header to reduce disk size

where you would use the atttypmod as the length instead of the header. But
a general solution like this would probably require too many structural
changes.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden