inet and cidr type problems
i have been playing with the inet and cidr types, and i have noticed a couple
problems, and would entertain suggestions as to how to fix them without
necessarily breaking how other people might be using them.
- a table with an element of type inet, will show "0.0.0.0/0" as "00/0"
i suspect this can be fixed in src/backend/adt/network.c or some such.
- when creating a table with either type inet or type cidr as a primary, unique
key, the elements "198.68.123.0/24" and "198.68.123.0/27" are considered
equal.
i considered editing src/backend/adt/network.c and changing the various
comparison functions to take the subnet bits into account, but i wasn't sure
what the proper fix is.
my feeling is to make "/27" to be greater than "/24", such that when fetching
in order, the "/24" will come first.
if i make such changes to the source, will it break other people's code if
the changes get added to the core source (6.4.3 or 6.5)?
--
[ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ]
[ The telephone, for those of you who have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail. ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]
This is still an open item
i have been playing with the inet and cidr types, and i have noticed a couple
problems, and would entertain suggestions as to how to fix them without
necessarily breaking how other people might be using them.- a table with an element of type inet, will show "0.0.0.0/0" as "00/0"
i suspect this can be fixed in src/backend/adt/network.c or some such.
- when creating a table with either type inet or type cidr as a primary, unique
key, the elements "198.68.123.0/24" and "198.68.123.0/27" are considered
equal.i considered editing src/backend/adt/network.c and changing the various
comparison functions to take the subnet bits into account, but i wasn't sure
what the proper fix is.my feeling is to make "/27" to be greater than "/24", such that when fetching
in order, the "/24" will come first.if i make such changes to the source, will it break other people's code if
the changes get added to the core source (6.4.3 or 6.5)?--
[ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ]
[ The telephone, for those of you who have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail. ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026I just ran a test in 6.5beta, and this still a problem:
test=> create table t (x inet primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index t_pkey for
table t
CREATE
test=> insert into t values ('198.68.123.0/24');
INSERT 18604 1
test=> insert into t values ('198.68.123.0/27');
ERROR: Cannot insert a duplicate key into a unique index
i have been playing with the inet and cidr types, and i have noticed a couple
problems, and would entertain suggestions as to how to fix them without
necessarily breaking how other people might be using them.- a table with an element of type inet, will show "0.0.0.0/0" as "00/0"
i suspect this can be fixed in src/backend/adt/network.c or some such.
- when creating a table with either type inet or type cidr as a primary, unique
key, the elements "198.68.123.0/24" and "198.68.123.0/27" are considered
equal.i considered editing src/backend/adt/network.c and changing the various
comparison functions to take the subnet bits into account, but i wasn't sure
what the proper fix is.my feeling is to make "/27" to be greater than "/24", such that when fetching
in order, the "/24" will come first.if i make such changes to the source, will it break other people's code if
the changes get added to the core source (6.4.3 or 6.5)?--
[ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ]
[ The telephone, for those of you who have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail. ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026i have been playing with the inet and cidr types, and i have noticed a couple
problems, and would entertain suggestions as to how to fix them without
necessarily breaking how other people might be using them.- a table with an element of type inet, will show "0.0.0.0/0" as "00/0"
This was fixed in 6.5.
i suspect this can be fixed in src/backend/adt/network.c or some such.
- when creating a table with either type inet or type cidr as a primary, unique
key, the elements "198.68.123.0/24" and "198.68.123.0/27" are considered
equal.
This has been addressed in 6.5 too.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026i have been playing with the inet and cidr types, and i have noticed a couple
problems, and would entertain suggestions as to how to fix them without
necessarily breaking how other people might be using them.- a table with an element of type inet, will show "0.0.0.0/0" as "00/0"
This was fixed in 6.5.
i suspect this can be fixed in src/backend/adt/network.c or some such.
- when creating a table with either type inet or type cidr as a primary, unique
key, the elements "198.68.123.0/24" and "198.68.123.0/27" are considered
equal.This has been addressed in 6.5 too.
cool.
i'm not sure how to query the bug list, so can you tell me if the following
problems have been addressed?
- ALTER TABLE tab_name RENAME TO new_name;
this command does not deal with extended tables (my name for when
a table physically exceeds 2Gig, on unix, and creates a second (third)
extent in the .../data/base/dbname dir.
- VACUUM VERBOSE;
has problems with extended tables, something like "cannot truncate
extended file".
--
[ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ]
[ The telephone, for those of you who have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail. ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]
This has been addressed in 6.5 too.
cool.
i'm not sure how to query the bug list, so can you tell me if the following
problems have been addressed?- ALTER TABLE tab_name RENAME TO new_name;
this command does not deal with extended tables (my name for when
a table physically exceeds 2Gig, on unix, and creates a second (third)
extent in the .../data/base/dbname dir.
Yes, I believe this is fixed.
- VACUUM VERBOSE;
has problems with extended tables, something like "cannot truncate
extended file".
I think this fix will be in 6.5.1, which should be next week.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026