Thread: 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 ]
> 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" 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 19026
> > 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"
>
> 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