| 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: | Whole Thread | Raw Message | 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 |