Mit PostgreSQL 9.4 gebunden:Postgres int4range oberen unerwarteten Wert
SELECT x, lower(x), upper(x) FROM (SELECT '[1,2]'::numrange x) q;
> [1,2] | 1 | 2 -- looks OK
SELECT x, lower(x), upper(x) FROM (SELECT '[1,2]'::int4range x) q;
> [1,3) | 1 | >>3<< -- this is unexpected
die weitere Lassen Sie prüfen:
SELECT x, lower(x), upper(x) FROM (SELECT '[1,3)'::numrange x) q1;
> [1,3) | 1 | 3 -- looks OK
SELECT x, lower(x), upper(x) FROM (SELECT '[1,3]'::numrange x) q1;
> [1,3] | 1 | 3 -- looks OK
Von pg Dokumentation:
obere (anyrange) | Bereich 's Elementtyp | Obergrenze des Bereichs | oben (Nummernbereich (1.1,2.2)) |
2,2
Während 3
technisch eine obere Schranke des ganzzahligen Bereichs [1,3) ∩ ℕ = {1, 2}
, so sind alle natürlichen Zahlen ≥ 2. Ich würde erwarten, dass die Funktion upper
kehrt der supremum (obere Grenze) des Bereichs.
Fehle ich etwas?
Ja, werden sie auf die kanonische Form umgewandelt. Und der Bereich [1,2] ist genau gleich ein [1,3] in N. Aber 3 in der sup. von keinem. – damians
@FireBiker Ja, 3 ist nicht das Supremum, aber es ist die Obergrenze (nach der Definition von PostgreSQL) von '[1,3)'. Sie können das 'upper_inc()' verwenden, um zu erkennen, ob es inklusiv ist oder nicht. Ich denke, das liegt daran, dass die Funktionen auf diese Weise konsistent sind (dh sowohl "upper ('[1,3)': int4range) 'als auch' upper (' [1,3) ':: numrange) 'ergeben' 3') - Beachten Sie, dass Supremum als die * kleinste obere Grenze * bezeichnet werden kann, während PostgreSQL nur den Begriff * obere Grenze * verwendet. – pozs