Re: tuple compare involving NULL
От | Tob |
---|---|
Тема | Re: tuple compare involving NULL |
Дата | |
Msg-id | 53EB8338.6050403@ibotty.net обсуждение исходный текст |
Ответ на | Re: tuple compare involving NULL (David G Johnston <david.g.johnston@gmail.com>) |
Ответы |
Re: tuple compare involving NULL
|
Список | pgsql-novice |
hi, > This isn't really useful context, to me at least. sorry to hear that. > It tells me nothing of why you need an artificial PK i don't understand what you mean with artificial. id _is_ the primary key. > or why you think a and b need to allow null. they do. i don't control the database layout and i have to support pagination involving NULLs in order by columns. > The where clause is odd with its mix of q and t in the same row value it is to allow ascending order on the first and descending order on the second. > and q.id is technically broken though I know this is just an > example. why is it? whenever (q.a, q.b) = (t.a, t.b) you need another (unique) key to seek to the next row. maybe i am missing things. > As muchas arbitrary default values suck they are at least better > than null in this regard. You can use coalesce for any data type. is there a special value (of every type) that is minimal for ever comparison (except with itself)? if so i could easily compare (COALESCE(t.a, MINIMAL VALUE), COALESCE(q.b, MINIMAL VALUE), t.id) thank you for your time, tobias florek
В списке pgsql-novice по дате отправления: