From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Cleaning up the INET/CIDR mess |
Date: | 2006-02-01 16:07:44 |
Message-ID: | 200602011607.k11G7il15887@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I agree. Let's do the zeroing and see if people complain about it.
>
> I'm complaining. Losing data on a cast is not common behavior.
[ Sorry for the delay.]
OK, that's clear. :-)
I looked around to see if I could find any places where we implicitly
cast and lose data. I tried factorial(3.2), and that cast failed.
However, if I do this explicit cast:
test=> SELECT '3.4'::float8::integer;
int4
------
3
(1 row)
it works. Can't we consider this:
test=> SELECT '1.2.3.4/24'::inet::cidr;
cidr
------------
1.2.3.0/24
(1 row)
a similar situation? inet is like float8 (bits beyond the masklen),
while cidr is like int4.
Is it only implicit casts you are worried about? Do we have any of
those left? All functions that take cidr also have an inet version, so
I don't see how an implicit cast to cidr could happen.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-01 16:08:58 | Re: Failed install - libgen.so doesn't exist |
Previous Message | Bruce Momjian | 2006-02-01 15:59:39 | Re: A note about testing EXEC_BACKEND on recent Linuxen |