Re: [HACKERS] TODO list check - Mailing list pgsql-hackers

> Peter Eisentraut <peter_e@gmx.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.

Re-added.

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

Re-added.

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

Re-added.

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

Re-added.

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


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