Re: [HACKERS] Re: inet/cidr/bind - Mailing list pgsql-hackers

From Paul A Vixie
Subject Re: [HACKERS] Re: inet/cidr/bind
Date
Msg-id 199810201743.KAA13773@bb.rc.vix.com
Whole thread Raw
In response to Re: [HACKERS] Re: inet/cidr/bind  ("Matthew N. Dodd" <winter@jurai.net>)
List pgsql-hackers
> Paul, thanks for taking the time to educate everyone here.  Your patience
> is appriciated and I only hope that the features you need will pan out in
> the release.

Be careful here.  My purported credentials in the networking field do not
necessarily translate to expertise in the database field.  I am a student
of computer languages, especially their type systems.  INET can be seen as
a supertype of (which means it can contain all the values) of IHOST.  But
there is no subtype or supertype relationship between CHOST and either INET
or IHOST.  Since Postgres is a very typey database, I am attracted to the
simple approach of creating INET (which is done now?), later on creating
IHOST as a subtype of it with different parsing/printing functions, and
using a pair of IHOSTs for any application which needs what CHOST does.

That's the computer language typing system approach, and the networking
approach.  I'm confident in those fields.  I am less so in the database
field -- the last database application I was paid to write was in 1981,
and that database was not even relational let alone object oriented.

IHOST and INET is how I'd implement this functionality in, say, Modula-3.
It also makes for a relatively compact and unambiguous (that is, easy to
generate a complete set of unit tests for) implementation.  But it's very
possible that I'm just an uneducated dolt when it comes to relational
object oriented databases and that anyone with more experience than I have
would automatically gravitate toward something like CHOST.

Quoting Mike Smith, "I am only an egg."


pgsql-hackers by date:

Previous
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] Re: inet/cidr/bind
Next
From: Paul A Vixie
Date:
Subject: Re: [HACKERS] Re: inet/cidr/bind