From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matthew N(dot) Dodd" <winter(at)jurai(dot)net> |
Cc: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] cidr |
Date: | 1998-07-21 14:46:27 |
Message-ID: | 23757.901032387@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Matthew N. Dodd" <winter(at)jurai(dot)net> writes:
> Plus, it would enable me to use my existing data without reloading.
> (ignoring the fact that 6.4 will probably require this.)
6.4 definitely will require a database reload, so as long as the
external representations are compatible this isn't a good argument
for a separate /32 type.
The space issue might be something to think about. But I'm inclined
to think that we should build in IPv6 support from the get-go, rather
than have to add it later. We ought to try to be ahead of the curve
not behind it. So it's gonna be more than 4 bytes/entry anyway.
Would it make sense to use atttypmod to distinguish several different
subtypes of CIDR? "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes
+ mask" seem like interesting possibilities.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 1998-07-21 14:51:45 | Re: [HACKERS] cidr |
Previous Message | Bruce Momjian | 1998-07-21 14:45:45 | Re: [HACKERS] cidr |