RE: [HACKERS] Re: inet/cidr/bind

Can't we just use a CONSTRAINT where a host address is expected? That sounds
easier than setting up two different types to me...

Taral

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Paul A Vixie
> Sent: Monday, October 19, 1998 2:08 PM
> To: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] Re: inet/cidr/bind
>
>
> > A network can certainly have a netmask. In fact, it always does. It
> > can be implied in certain cases. The following (if I understand Paul's
> > proposal - correct me if not) show the relationships.
> >
> > Input cidr output inet output
> > ============= ================ ================
> > 192.63.91.234 192.63.91.234/32 192.63.91.234/32
> > 192.63.91 192.63.91/24 192.63.91.0/24
> > 192.63 192.63/16 192.63.0.0/16
> > 192 192/8 192.0.0.0/8
> >
> > This look right to you, Paul?
>
> no. the last three inputs are not valid where a host address is expected.
>
> > > If I am wrong about the above, I have one more question. Would an
> > > atttypmod setting for each column help? What about a compile-time
> > > define?
> >
> > We discussed this at one point. I think that is more useful for
> > specifying output formats. For example, 192.63.91.234/24 is identical
> > to 192.63.91.234:255.255.255.0 (if we add that format) but I think
> > that's 6.4++ too. I think it would also only apply to the inet type
> > but Paul should know.
> >
> > > I know Paul is a big name, but are the duplicate types meaningful for
> > > ordinary users, or would they prefer just one type. If they would
> > > prefer one type, we can do that, and make sure Paul gets what he wants
> > > too.
> >
> > I understand why Paul needs his type but I think the inet type is
> > valuable too. I think my suggestion above is a good compromise.
>
> bigness of names doesn't matter. applications matter. i can see
> a use for
> both types, but they are inherently different types. a host that has a
> netmask which can be expressed in cidr notation is one such type. a net
> that has a netmask which must be expressed in cidr notation is
> another such
> type. the difference comes down to "host part must be zero" for
> the network
> type. there are also some minor differences in the input/output formats,
> since a host address always has four octets on both input and
> output, while
> a network only prints as many octets as the cidr width specifies,
> and these
> are the only required octets on input (though extra .0's can be
> specified).
>
> > I think we are just about there. If we go with my plan (completely
> > different functionality for now and fold it later) there should be
> > no API change later. There will be code and catalogue changes but
> > they should be relatively painless.
>
> so shall i test the inet_cidr_ functions and punt them on in?
>
>