Mark Woodward wrote:
> > It turns out what you like actually exists, lookup the "service"
> > parameter in the connectdb string. It will read the values for the
> > server, port, etc from a pg_service.conf file.
> >
> > There is an example in the tree but it looks something like the following:
> >
On Feb 19, 2006, at 10:59 AM, Mark Woodward wrote:
"Mark Woodward" <[EMAIL PROTECTED]> writes:
DNS isn't always a better solution than /etc/hosts, both have
their pros
and cons. The /etc/hosts file is very useful for "instantaneous,"
reliable, and redundent name lookups. DNS services, espci
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> Um, is there something wrong with having multiple DNS servers in
>> resolv.conf? Other than having to time out on #1 before you try #2?
>> I'm genuinely curious.
>
> What is the "timeout" of that DNS lookup, before it goes to the second DNS
> server?
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>
>> DNS isn't always a better solution than /etc/hosts, both have their pros
>> and cons. The /etc/hosts file is very useful for "instantaneous,"
>> reliable, and redundent name lookups. DNS services, espcially in a large
>> service environment can get
> Mark Woodward wrote:
>> Don't get me wrong, DNS, as it is designed, is PERFECT for the
>> distributed nature of the internet, but replication of fairly static
>> data under the control of a central authority (the admin) is better.
>
> What about this zeroconf/bonjour stuff? I'm not familiar with
> Martijn van Oosterhout writes:
>> I think the major issue is that most such systems (like RFC2782) deal
>> only with finding the hostname:port of the service and don't deal with
>> usernames/passwords/dbname. What we want is a system that not only
>> finds the service, but tells you enough to co
Martijn van Oosterhout writes:
> I think the major issue is that most such systems (like RFC2782) deal
> only with finding the hostname:port of the service and don't deal with
> usernames/passwords/dbname. What we want is a system that not only
> finds the service, but tells you enough to connect.
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> DNS isn't always a better solution than /etc/hosts, both have their pros
> and cons. The /etc/hosts file is very useful for "instantaneous,"
> reliable, and redundent name lookups. DNS services, espcially in a large
> service environment can get bogged
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Don't get me wrong, DNS, as it is designed, is PERFECT for the
>> distributed nature of the internet, but replication of fairly static
>> data under the control of a central authority (the admin) is better.
>
> What about this
On Sun, Feb 19, 2006 at 04:56:11PM +0100, Peter Eisentraut wrote:
> Mark Woodward wrote:
> > Don't get me wrong, DNS, as it is designed, is PERFECT for the
> > distributed nature of the internet, but replication of fairly static
> > data under the control of a central authority (the admin) is bette
Mark Woodward wrote:
> Don't get me wrong, DNS, as it is designed, is PERFECT for the
> distributed nature of the internet, but replication of fairly static
> data under the control of a central authority (the admin) is better.
What about this zeroconf/bonjour stuff? I'm not familiar with it, but
> On Sun, 2006-02-19 at 10:00 -0500, Mark Woodward wrote:
>> > On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
>> >> Like I said, in this thread of posts, yes there are ways of doing
>> this,
>> >> and I've been doing it for years. It is just one of the rough eges
>> that
>> >> I
>>
> On Sun, Feb 19, 2006 at 10:00:01AM -0500, Mark Woodward wrote:
>> > It turns out what you like actually exists, lookup the "service"
>> > parameter in the connectdb string. It will read the values for the
>> > server, port, etc from a pg_service.conf file.
>> >
>> > There is an example in the tre
On Sun, Feb 19, 2006 at 09:58:01AM -0500, Douglas McNaught wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > A server-side (i.e. centrally managed) name server seems like an
> > improvement over the client-side solutions described, IMHO, but I'd
> > leave it to others to describe how that mig
Simon Riggs <[EMAIL PROTECTED]> writes:
> A server-side (i.e. centrally managed) name server seems like an
> improvement over the client-side solutions described, IMHO, but I'd
> leave it to others to describe how that might work. (e.g. DNS is a
> better solution than multiple distributed /etc/hos
On Sun, Feb 19, 2006 at 10:00:01AM -0500, Mark Woodward wrote:
> > It turns out what you like actually exists, lookup the "service"
> > parameter in the connectdb string. It will read the values for the
> > server, port, etc from a pg_service.conf file.
> >
> > There is an example in the tree but i
On Sun, 2006-02-19 at 10:00 -0500, Mark Woodward wrote:
> > On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
> >> Like I said, in this thread of posts, yes there are ways of doing this,
> >> and I've been doing it for years. It is just one of the rough eges that
> >> I
> >> think coul
> On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
>> Like I said, in this thread of posts, yes there are ways of doing this,
>> and I've been doing it for years. It is just one of the rough eges that
>> I
>> think could be smoother.
>>
>> (in php)
>> pg_connect("dbname=geo host=dbser
18 matches
Mail list logo
