You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Date: 2014-12-25 00:33:14 +0100
From: K <>
To: SQL devs <>
Version: 11.19.7 (Oct2014-SP1)
Last updated: 2015-01-29 14:07:16 +0100
Comment 20548
Date: 2014-12-25 00:33:14 +0100
From: K <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build Identifier:
Given a table with an 'inet' datatype column, displaying the rows using the ORDER BY clause results in incorrect ordering. This appears to be an endian issue.
Reproducible: Always
Steps to Reproduce:
CREATE TABLE "testing" ( "addr" inet );
INSERT INTO "testing" VALUES('192.168.0.1');
INSERT INTO "testing" VALUES('255.255.255.0');
SELECT * FROM "testing" ORDER BY addr;
Actual Results:
255.255.255.0
192.168.0.1
i.e. the addresses are being sorted on the bases of the LOW byte first, rather than the HIGH byte.
Expected Results:
192.168.0.1
255.255.255.0
The expected ordering
What the example does not make clear (because it's so short) is that if you have a table with 1000 addresses, the ORDER BY result will appear essentially random because the sorting for an address like A.B.C.D sorts by D first, then C, then B, and then A.
This is what you might expect if the addresses are being stored as simple unsigned integers in host byte order (since x86_64 is little-endian). A quick solution might be to always store network addresses in network byte order and make sure to use the proper comparison.
Added inet.cmp function. We cannot rely on inherited lngCmp.
Unfortunately, we cannot trust the (rev)sorted flags on inet columns
in older databases, so we need to increment the BBP version number and
squash those flags when the database is upgraded.
This fixes bug #3646.
Date: 2014-12-25 00:33:14 +0100
From: K <>
To: SQL devs <>
Version: 11.19.7 (Oct2014-SP1)
Last updated: 2015-01-29 14:07:16 +0100
Comment 20548
Date: 2014-12-25 00:33:14 +0100
From: K <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build Identifier:
Given a table with an 'inet' datatype column, displaying the rows using the ORDER BY clause results in incorrect ordering. This appears to be an endian issue.
Reproducible: Always
Steps to Reproduce:
Actual Results:
255.255.255.0
192.168.0.1
i.e. the addresses are being sorted on the bases of the LOW byte first, rather than the HIGH byte.
Expected Results:
192.168.0.1
255.255.255.0
The expected ordering
What the example does not make clear (because it's so short) is that if you have a table with 1000 addresses, the ORDER BY result will appear essentially random because the sorting for an address like A.B.C.D sorts by D first, then C, then B, and then A.
This is what you might expect if the addresses are being stored as simple unsigned integers in host byte order (since x86_64 is little-endian). A quick solution might be to always store network addresses in network byte order and make sure to use the proper comparison.
Comment 20554
Date: 2015-01-14 14:25:33 +0100
From: MonetDB Mercurial Repository <>
Changeset f81a9bd3789b made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=f81a9bd3789b
Changeset description:
Comment 20594
Date: 2015-01-29 14:07:16 +0100
From: @sjoerdmullender
Oct2014-SP2 has been released.
The text was updated successfully, but these errors were encountered: