Re: [HACKERS] TODO list check
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] TODO list check |
Дата | |
Msg-id | 7234.949017952@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | TODO list check (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] TODO list check
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] TODO list check (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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. 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 readsselect q1 from int8_tbl union select f1 from int4_tbl group by f1;fails (subtly) because wrong sortopis 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
В списке pgsql-hackers по дате отправления:
Следующее
От: Chris BitmeadДата:
Сообщение: Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns)