Re: [GENERAL] inet and cidr type problems

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Jim Mercer <jim(at)reptiles(dot)org>
Cc: PostgreSQL-development <hackers(at)postgreSQL(dot)org>
Subject: Re: [GENERAL] inet and cidr type problems
Date: 1999-05-09 15:51:58
Message-ID: 199905091551.LAA23094@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


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(at)reptiles(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jonny Hinojosa 1999-05-09 16:01:59 RE: [GENERAL] Regression test failures
Previous Message Bruce Momjian 1999-05-09 15:33:06 Re: [GENERAL] inet and cidr type problems

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-09 15:53:01 Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc
Previous Message Bruce Momjian 1999-05-09 15:33:06 Re: [GENERAL] inet and cidr type problems