Re: [HACKERS] TODO list check

TODO list updated with your suggestions.

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> 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
> 
> 
> 
> ************
> 


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@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