| From: | Alexey Bashtanov <bashtanov(at)imap(dot)cc> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Ilya Bashtanov <bashtanov(at)gmail(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Subject: | Timetz comparison |
| Date: | 2018-05-25 22:08:04 |
| Message-ID: | acf5d520-2807-dff4-a52a-b37a551d97df@imap.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
Comparison of timetz values looks a bit weird to me, as
'22:00+02'::timetz > '21:00+01'::timetz.
I can see this behavior introduced by commit 2792374c in 2001
with the comment "timetz was just plain broken (some possible pairs of
values were neither < nor = nor >)".
The in-code comment is:
/*
* If same GMT time, sort by timezone; we only want to say that two
* timetz's are equal if both the time and zone parts are equal.
*/
However I found no specification on how timetz values are compared
neither in postgres docs
nor in the standard (http://www.wiscorp.com/sql20nn.zip)
Was this decision made just to be definite?
What's the problem with these values to be considered equal?
Backward compatibility? Hash algorithms?
Thanks
Best regards,
Alexey
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-05-25 22:33:05 | Re: Timetz comparison |
| Previous Message | Andres Freund | 2018-05-25 22:05:31 | Re: found xmin from before relfrozenxid on pg_catalog.pg_authid |