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 ]

Wed, 3 Mar 1999 23:40:40 -0500 (EST)
jim@reptiles.org (Jim Mercer)
inet and cidr type problems

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 19026

Sun, 9 May 1999 11:33:06 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] inet and cidr type problems

I 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 19026

Sun, 9 May 1999 11:51:58 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] 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"

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

Tue, 6 Jul 1999 22:06:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] 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"
> 
> 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 ]

Wed, 7 Jul 1999 02:10:38 -0400 (EDT)
jim@reptiles.org (Jim Mercer)
Re: [GENERAL] inet and cidr type problems
> > 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

Wed, 7 Jul 1999 03:44:22 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] inet and cidr type problems