On Jan 11, 2008, at 3:00 PM, Andrew Sullivan wrote:
On Fri, Jan 11, 2008 at 02:38:27PM -0800, Steve Atkins wrote:
I don't think there's ambiguity about what an dotted-quad without a
netmask
means, and hasn't been for a long time. Am I missing something?
Well, maybe. The problem is actually that, without a netmask under
CIDR,
the address alone isn't really enough. You have to have a netmask
to get
the packets to the destination.
Not really. You may well need netmasks to configure your interface, but
there's absolutely no need for them to identify an IP endpoint, which
is all
you need to identify the destination the packet is going to, and that
is the
most common use of IP addresses.
As it happens, we have some nice
conventions, defined in the RFCs, for how to interpret hosts with no
netmask; note though that some of those are only for humans. Or, to
put it
another way, without context, a dotted-quad is insufficient on its
own.
What you're really arguing is that the context ought to be storable
somewhere else (maybe in a human's brain).
A dotted quad without any additional information is an IPv4 address,
the same as it would be if followed by "/32".
Netmasks are rarely needed at any level above routing
or (some forms of) address assignment, and that's where an awful lot
of use of IP
addresses happens. When you do need netmasks then the cidr type is
great, but that's not the common case.
(And the inet-with-a-netmask is an even odder duck, as it's packing
two mostly
unrelated bits of information into a single type).
I'm not suggesting that's wrong,
but I can see the "correctness" argument that someone might have
made to get
to the datatype as it exists. I think calling it "needless bloat"
is just
holding it to the wrong criteria.
If you look at the binary wire data, that netmask is always
represented in
some sense. It can sometimes be more compact than the general-
purpose data
type, though, no question. This is why somewhere in this thread
someone
talked about optimisation: there certainly are ways to make these
things
more compact.
I think we're drifting a long way away from a -performance topic here,
as
we're agreed that inet or cidr are likely not the best types for the
original
poster to use.
Cheers,
Steve
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
