Re: [HACKERS] cidr

> > I like INET too. It is up to you.
>
> How do folks feel about polymorphism between IPv4 and IPv6? Should we (a)
> make it work (either by making internal_length=10 or going variable length)
> or (b) just make this thing IPv4 only and take care of IPv6 separately/later?

I say stick with IPv4 at this point. We can always change it in future
upgrades. dump/reload will handle any changes in the internal format.

>
> I've started to wonder if we ought to call the type INET and limit it to V4.
> (In the C socket bindings, IPv6 addresses are in_addr6 / sockaddr_in6, and
> the address family is AF_INET6 -- I don't know whether to plan on reflecting
> this in the postgres types, i.e., use a separate one for IPv6, or not.)

We can call it INET now, and change it to INET4/INET6 if we decide we
want separate types for the two address types.

>
> > From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> > Date: Tue, 21 Jul 1998 01:30:05 -0400 (EDT)
> >
> > > ... but why would you want to know the mantissa without the scale?
> >
> > I guess I thought someone might want to have ipaddr() and netmask()
> > functions so they can do:
> >
> > x = 192.7.34.21/24
> > ipaddr(x) -> 192.7.34.21
> > netmask(x) -> 255.255.255.0
>
> This is the downreference from above. It does not work that way. /24 is
> not a shorthand for specifying a netmask -- in CIDR, it's a "prefix length".
> That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent
> to "192.7.34/24".

How do we store the netmask? Is that a separate field?

>
> Btw, it appears from my research that the BIND functions *do* impute a "class"
> if (a) no "/width" is specified and (b) the classful interpretation would be
> longer than the classless interpretation. No big deal but it qualifies
> something I said earlier so I thought I'd mention it.
>
> > x = 192.7.0.0/16
> > ipaddr(x) -> 192.7.0.0
> > netmask(x) -> 255.255.0.0
> >
> > These function are defined on the cidr type, and can be called if
> > someone wants the old output format.
>
> Can we wait and see if someone misses / asks for these before we make them?

Suppose I want to retrieve only 'host' addresses. How do we do that?

> > Doing complex stuff like indexing with contrib stuff is tricky, and one
> > reason we want to move stuff out of there as it becomes popular. It is
> > just too hard for someone not experienced with the code to implement.
> > Add to this the fact that the oid at the time of contrib installation
> > will change every time you install it, so it is even harder/impossible
> > to automate.
>
> Perhaps we ought to make new type insertion easier since it's so cool?

Yep, it is cool. When the code is installed as a standard part of the
backend, you have more facilities to install types. There are examples
of many other types in the include/catalog/*.h files, so you just pick
one and duplicate the proper partsTrying to do that with an SQL
statement is really messy, particularly because the standard types DON'T
use SQL to install themselves. You also must specify unique OIDs for
these new entries. Also, the terminology is not something that many
people are familiar with, so a lot of it is having the user understand
what they need to do. The manuals do a pretty good job. If you have
any specific ideas, or things that got you confused that we should
clearify, please let us know.

Fortunately, there are only a few types in the /contrib area, and as you
have learned. As people find the types useful, we want to move them
into the main source.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)