On 10/11/2013, at 4:24, Peter Corlett wrote:
> On 8 Nov 2013, at 19:33, David Cantrell wrote:
> [...]
>> Because you might need to know which of two events at 2013-11-08Z19:31:04
>> happened first. Sure you could use microseconds or whatever to get better
>> resolution, but all that does is make the problem less likely, it doesn't
>> make it go away. You also normally want sort order to be consistent. If you
>> have two records where the sort field is the same, the order they come out
>> is going to be unpredictable.
>
>
> That's just a specific example of the general problem where one desires a
> stable sort by a non-unique column. The simple solution is to just add more
> columns to the ORDER BY until the tuples *are* unique. The primary key is an
> obvious choice of tie-breaker if you don't care about the order so long as
> it's consistent.
Also, the time I tried to use a date field for ordering, it wasn't susceptible
to this problem for reasons related to the specific use case. It was still a
bad idea though, for scope-creep related reasons.
