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@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Paul A Vixie
> Sent: Monday, October 19, 1998 2:08 PM
> To: pgsql-hackers@postgreSQL.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?
>
>