Skip site navigation (1) Skip section navigation (2)

Re: Summary: what to do about INET/CIDR

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Summary: what to do about INET/CIDR
Date: 2000-10-27 20:07:00
Message-ID: 2755.972677220@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Larry Rosenman <ler(at)lerctr(dot)org> writes:
> OK, what I really meant was a way to coerce a CIDR entity to INET so 
> that host() can work with a CIDR type to print all 4 octets. 

Hm.  I don't see any really good reason why host() rejects CIDR input
in the first place.  What's wrong with producing the host address
that corresponds to extending the CIDR network address with zeroes?

> Currently you can't coerce a CIDR type to INET. 

Well you can, but it doesn't *do* anything.  One of the peculiarities
of these two types is that the cidr-vs-inet flag is actually stored
in the data value.  The type-system differentiation between CIDR and
INET is a complete no-op for everything except initial entry of a value
(ie, conversion of a text string to CIDR or INET); all the operators
that care (which is darn few ... in fact it looks like host() is the
only one!) look right at the value to see which type they've been given.
So applying a type coercion may make the type system happy, but it
doesn't do a darn thing to the bits, and thus not to the behavior of
subsequent operators either.  I have not yet figured out if that's a
good thing or a bad thing ...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Larry RosenmanDate: 2000-10-27 20:11:09
Subject: (forw) Re: Summary: what to do about INET/CIDR
Previous:From: Lamar OwenDate: 2000-10-27 20:04:39
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group