From: | Tob <me(at)ibotty(dot)net> |
---|---|
To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: tuple compare involving NULL |
Date: | 2014-08-13 15:24:40 |
Message-ID: | 53EB8338.6050403@ibotty.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Florek | 2014-08-13 15:25:43 | Re: tuple compare involving NULL |
Previous Message | Tom Lane | 2014-08-13 15:00:16 | Re: tuple compare involving NULL |