[EMAIL PROTECTED] ("Mark Woodward") writes:
> The "port" aspect is troubling, it isn't really self
> documenting. The application isn't psql, the applications are custom
> code written in PHP and C/C++.Nonsense. See /etc/services > Using the "/etc/hosts" file or DNS to maintain host locations for is > a fairly common and well known practice, but there is no such > mechanism for "ports." The problem now becomes a code issue, not a > system administration issue. Nonsense. See /etc/services > If one writes the code to their website to use a generic host name, > say, "dbserver," then one can easily test system changes locally and > push the code to a live site. The only difference is the host > name. When a port is involved, there is no systemic way to represent > that to the operating system, and must therefor be part of the > code. As part of the code, it must reside in a place where code has > access, and must NOT be pushed with the rest of the site. > > Having some mechanism to deal with this would be cleaner IMHO. I'm sure it would be, that's why there has been one, which has been in use since the issuance of RFC 349 by Jon Postel back in May of 1972. The mechanism is nearly 34 years old. Note that RFCs are no longer used to issue port listings, as per RFC 3232, back in 2002. Now, IANA manages a repository of standard port numbers, commonly populated into /etc/services. <http://www.iana.org/assignments/port-numbers> For customizations, see: % man 5 services -- (format nil "[EMAIL PROTECTED]" "cbbrowne" "acm.org") http://www.ntlug.org/~cbbrowne/sgml.html "Motto for a research laboratory: What we work on today, others will first think of tomorrow." -- Alan J. Perlis ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
