represented as "char ...[4]" not "int32".  Since the length word is never
supposed to be accessed via this struct member anyway, this won't break
any existing code that is following the rules.  The advantage is that C
compilers will no longer assume that a pointer to struct varlena is
word-aligned, which prevents incorrect optimizations in TOAST-pointer
access and perhaps other places.  gcc doesn't seem to do this (at least
not at -O2), but the problem is demonstrable on some other compilers.

I changed struct inet as well, but didn't bother to touch a lot of other
struct definitions in which it wouldn't make any difference because there
were other fields forcing int alignment anyway.  Hopefully none of those
struct definitions are used for accessing unaligned Datums.

This commit breaks any code that assumes that the mere act of forming a tuple
(without writing it to disk) does not "toast" any fields.  While all available
regression tests pass, I'm not totally sure that we've fixed every nook and
cranny, especially in contrib.

Greg Stark with some help from Tom Lane

back-stamped for this.

header files.

and rely exclusively on the SQL type system to tell the difference between
the types.  Prevent creation of invalid CIDR values via casting from INET
or set_masklen() --- both of these operations now silently zero any bits
to the right of the netmask.  Remove duplicate CIDR comparison operators,
letting the type rely on the INET operators instead.

Tag appropriate files for rc3

Also performed an initial run through of upgrading our Copyright date to
extend to 2005 ... first run here was very simple ... change everything
where: grep 1996-2004 && the word 'Copyright' ... scanned through the
generated list with 'less' first, and after, to make sure that I only
picked up the right entries ...

cidr type bit, the same as network_eq does.  This is needed for hash joins
and hash aggregation to work correctly on these types.  Per bug report
from Michael Fuhr, 2004-04-13.
Also, improve hash function for int8 as suggested by Greg Stark.

make sure the $Id tags are converted to $PostgreSQL as well ...

        Regression tests for IPv6 operations added.

        Documentation updated to document IPv6 bits.

        Stop treating IPv4 as an "unsigned int" and IPv6 as an array of
        characters.  Instead, always use the array of characters so we
        can have one function fits all.  This makes bitncmp(), addressOK(),
        and several other functions "just work" on both address families.

        add family() function which returns integer 4 or 6 for IPv4 or
        IPv6.  (See examples below)  Note that to add this new function
        you will need to dump/initdb/reload or find the correct magic
        to add the function to the postgresql function catalogs.

        IPv4 addresses always sort before IPv6.

        On disk we use AF_INET for IPv4, and AF_INET+1 for IPv6 addresses.
        This prevents the need for a dump and reload, but lets IPv6 parsing
        work on machines without AF_INET6.

        To select all IPv4 addresses from a table:

                select * from foo where family(addr) = 4 ...

        Order by and other bits should all work.

Michael Graff

initdb/regression tests pass.

tests pass.

on myself to do something about the non-self-consistency of the inet
comparison functions.  The results are probably still semantically wrong
(inet and cidr should have different comparison semantics, I think)
but at least the boolean operators now agree with each other and with
the sort order of indexes on inet/cidr.

now TOAST-able.

  * Portions Copyright (c) 1996-2000, PostgreSQL, Inc

to all files copyright Regents of Berkeley.  Man, that's a lot of files.

debate was from Paul Vixie, who wanted INET to be the name covering
both IPV4 and IPV6.  The following kit makes the needed changes:

Tom Ivar Helbekkmo