From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Summary: what to do about INET/CIDR |
Date: | 2000-11-05 02:47:09 |
Message-ID: | Pine.LNX.4.21.0011050340090.775-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> 3. The function host(inet) will return a text representation of
> just the IP part of an INET or CIDR value, eg, "127.1.0.0".
> All four octets will always appear, the netmask will never appear.
> (This is the same as its current behavior, I think.)
I think there was definite merit in the host() function returning inet, as
you originally proposed (if only for consistency with the proposed changes
to network() and broadcast()).
A separate function for formatting output seems necessary, but if we don't
reach an agreement though, it ought to work to cast CIDR to INET to get
all four octets, no?
> 4. A new function text(inet) will return a text representation of
> both the IP and netmask parts of an INET or CIDR value, eg,
> "127.1.0.0/16". Unlike the default display conversions, all four
> octets and the netmask length will always appear in the result.
> Note that the system will consider this function to be a typecast,
> so the same result can be gotten with inetval::text or
> CAST(inetval AS text).
I think the typecast-to-text representation of CIDR should be visually the
same as the normal representation.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-11-05 03:29:53 | Thoughts on 7.0.3 pg_dump addition |
Previous Message | Tom Lane | 2000-11-05 02:46:02 | Re: Summary: what to do about INET/CIDR |