Re: [HACKERS] Re: inet/cidr/bind
От | Paul A Vixie |
---|---|
Тема | Re: [HACKERS] Re: inet/cidr/bind |
Дата | |
Msg-id | 199810201743.KAA13773@bb.rc.vix.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: inet/cidr/bind ("Matthew N. Dodd" <winter@jurai.net>) |
Список | 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 по дате отправления: