Re: Cleaning up the INET/CIDR mess

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

In response to

Responses

Browse pgsql-hackers by date

  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