Re: Cleaning up the INET/CIDR mess

Поиск
Список
Период
Сортировка
От Andrew Sullivan
Тема Re: Cleaning up the INET/CIDR mess
Дата
Msg-id 20060124215410.GH7199@phlogiston.dyndns.org
обсуждение исходный текст
Ответ на Cleaning up the INET/CIDR mess  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jan 24, 2006 at 01:23:17PM -0500, Tom Lane 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.)

I'd argue for an error, on correctness grounds (someone's bound to
come back having misused these, and complain that it silently changed
data.  They'd have a point).

> One other point is what to do with the binary I/O functions (send/receive)
> for inet and cidr.  I think that we should continue to send the is_cidr
> flag byte for backwards-compatibility reasons.  On receive, we could
> either ignore that byte entirely, or insist that it match the expected
> datatype.  I'm inclined to ignore the byte but am willing to listen to
> arguments to raise an error instead.

If this is exposed to users in some way (I don't think it is, is it?)
then I'd argue for erroring, on the same grounds of what I say above. 
But otherwise, I think you could ignore it.

A


-- 
Andrew Sullivan  | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what 
you told them to.  That actually seems sort of quaint now.    --J.D. Baldwin


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

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: [PATCHES] postmaster/postgres merge for testing
Следующее
От: Seneca Cunningham
Дата:
Сообщение: Some platform-specific MemSet research