From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Cleaning up the INET/CIDR mess |
Date: | 2006-01-24 23:54:41 |
Message-ID: | slrndtdfi1.d6t.andrew+nonews@atlantis.supernews.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2006-01-24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Without the flag, it's okay for cidr-to-inet to be a binary-compatible (no
> function) conversion. However, inet-to-cidr has to either zero out bits
> to the right of the netmask, or error out if any are set. Joachim Wieland
> posted a patch that makes the coercion function just silently zero out any
> such bits. That's OK with me, but does anyone want to argue for an error?
> (If we do make the coercion function raise error, then we'd probably need
> to provide a separate function that supports the bit-zeroing conversion.)
>
> Currently, both directions of cast are implicit, but that is a bad idea.
> I propose keeping cidr-to-inet as implicit but making inet-to-cidr an
> assignment cast. This fits with the fact that inet can represent all
> values of cidr but not vice versa (compare int4 and int8).
If inet-to-cidr can zero out bits silently, then wouldn't making it an
assignment cast be rather dangerous and error-prone?
> Given the implicit binary-compatible coercion, it's OK to have just a
> single function taking inet for any case where the function truly doesn't
> care if it's looking at inet or cidr input. For the cases where the code
> currently pays attention to is_cidr, we'd have to make two separate
> functions. AFAICT that's only abbrev(inet) and text(inet) among the
> current functions. Also, set_masklen(inet,integer) would have to come
> in two flavors since the output type should be the same as the input.
You sometimes need set_masklen(cidr,integer) returning inet, and I'd bet
there's existing code that does that.
> The relationship of cidr and inet would be a little bit like the relation
> between varchar and text. For instance, varchar doesn't have any
> comparison operators of its own, but piggybacks on text's comparison
> operators, relying on the implicit cast from varchar to text to make this
> transparent to users.
Well, inet/cidr have far more justification for being separate types than
text/varchar do - the text/varchar issue causes a great deal of confusion.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2006-01-25 01:23:31 | Re: Weird pg_dumpall bug? |
Previous Message | Martijn van Oosterhout | 2006-01-24 22:49:46 | Re: Some platform-specific MemSet research |