> 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=dbserver");
>>
>> Could connect and query the dbserver, if the db is not on it, connect to
>> a
>> database of known servers, find geo, and use that information to
>> connect.
>> It sounds like a simple thing, for sure, but to be useful, there needs
>> to
>> be buy in from the group otherwise it is just some esoteric hack.
>
> 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:
>
> [servicename]
> dbname=blah
> user=blah
> pass=blah
>
> So all you need to specify is "service=servicename" and it will grab
> the parameters. This allows you to change the connection without
> changeing the code.
>This is a great feature!! It doesn't seem to be documented in the administrators guide. Its mentioned in the libpq section, and only a reference to pg_service.conf.sample IMHO we should push for this to be the mainstream connection methodology!!! The variables: host, port, and dbname are very problematic for admins and developers who often live in different worlds. The developers "should" just use the "servicename" of a database, and the admins should maintain pg_service.conf. This moves the responsibility of the wheres and hows of connecting to the database to the admin away from the developer. Should there be a section of the administration manual for this? ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
