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>, Alex Pilosov <alex(at)pilosoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Second proposal: what to do about INET/CIDR |
Date: | 2000-10-28 12:21:06 |
Message-ID: | Pine.LNX.4.21.0010281413470.763-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> 3. We will add explicit functions cidr(inet) and inet(cidr) to force
> the data type to one or the other style, thus allowing selection
> of either display style. Note that cidr(inet) will raise an error
> if given something with nonzeroes to the right of the netmask.
Not sure if using functions that look like a cast to control output format
is a good idea. The conversion inet => cidr seems most naturally left
with the network() function. The other conversion is not well-defined.
(You could define it in several reasonable ways, but that still doesn't
make it "well".) ISTM that you'd really need some function build_inet(a
cidr, b inet) returns inet, where b does not have a network and can
somehow be fitted into network a.
Actually, let's sign up Karel to write to_char(inet) and to_char(cidr).
> But in the long run it might be better to remove the
> binary-equivalence.
I say kill it ASAP. I don't think there was ever a good reason for this
besides implementation convenience; and the troubles it has caused are
without end.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-10-28 13:34:00 | Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) |
Previous Message | Peter Eisentraut | 2000-10-28 12:13:23 | Re: Summary: what to do about INET/CIDR |