Re: [HACKERS] Upgrades for 6.4.1
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Upgrades for 6.4.1 |
Дата | |
Msg-id | 5478.914089369@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Upgrades for 6.4.1 ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] Upgrades for 6.4.1
|
Список | pgsql-hackers |
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: >> * SELECT DISTINCT i FROM dtest ORDER BY j generates strange output > In my simple test case, it orders by j, then only shows i. Is that > strange? The thing that is "strange" is that you get nonunique values of i, which is definitely a bit unexpected for "SELECT DISTINCT": play=> SELECT * FROM dtest; i| j -+-- 1|10 1|11 1|12 2|20 3|30 (5 rows) play=> SELECT DISTINCT i FROM dtest ORDER BY j; i - 1 1 1 2 3 (5 rows) The reason that this is happening is that the "distinct" filter is actually being run on i,j not just i (see "distinct + order by" thread in the hackers archives around 8-Nov-98). I don't know whether the SQL standard defines how this combination of features ought to work ... but our current behavior seems fairly surprising... >> * Allow constraint NULL just as we honor NOT NULL > Fundamental yacc problem with this as I recall. Gives rise to > shift/reduce problems since it is ambiguous with other uses of "NULL" in > the same area. More to the point, what possible use would a column constrained to NULL be? Might as well just not have it in the table... regards, tom lane
В списке pgsql-hackers по дате отправления: