Re: Cleaning up the INET/CIDR mess

Поиск
Список
Период
Сортировка
От Andrew - Supernews
Тема Re: Cleaning up the INET/CIDR mess
Дата
Msg-id slrndtdfi1.d6t.andrew+nonews@atlantis.supernews.net
обсуждение исходный текст
Ответ на Cleaning up the INET/CIDR mess  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Cleaning up the INET/CIDR mess  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
On 2006-01-24, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Some platform-specific MemSet research
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Weird pg_dumpall bug?