On 21 Feb 2006, at 10:42, Martijn van Oosterhout wrote:
On Tue, Feb 21, 2006 at 10:02:58AM +0100, Albe Laurenz wrote:
Thank you also for drawing my attention to pg_service.conf - I
have not
been aware of it.
There are two 'shortcomings':
- It still means that you have to change the config
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP name resolution cuts in.
- Before
Albe Laurenz wrote:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set,
A little off-topic, but related: PeterE recently complained about an
option in pgAdmin which is called service. Its
Albe Laurenz wrote:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP name resolution cuts in.
I have added a configure option --with-openldap to enable the code.
Does that make sense to you?
Should I try to polish and test the code and submit it as a patch
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just
Albe Laurenz [EMAIL PROTECTED] writes:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP
Uh, why is it a good idea to overload the service option like that?
ISTM it'd be less confusing to use a separate option. Further I
suggest
that pg_service ought to be handled first, ie, it makes sense to me to
be able to put both the LDAP name and the LDAP server address(es) into
a
Andrew Dunstan [EMAIL PROTECTED] writes:
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just fine if openldap
is available). Then we could fetch the config from a variety of sources,
not just ldap.
What other cases
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just fine if openldap
is available). Then we could fetch the config from a variety of sources,
not just
Thanks to everybody who answered.
Maybe it is really the best thing to use a tool like postgresql-relay or
pgpool - I will investigate these.
I'm not eager to reinvent the wheel.
We have considered relocating DNS entries, but the problem is that a
changed
DNS entry takes long to propagate; in
On Tue, Feb 21, 2006 at 10:02:58AM +0100, Albe Laurenz wrote:
Thank you also for drawing my attention to pg_service.conf - I have not
been aware of it.
There are two 'shortcomings':
- It still means that you have to change the config file on every
client.
Well yes. However, you could
Albe Laurenz wrote:
Thanks to everybody who answered.
Maybe it is really the best thing to use a tool like postgresql-relay or
pgpool - I will investigate these.
I'm not eager to reinvent the wheel.
We have considered relocating DNS entries, but the problem is that a
changed
DNS entry takes
On Mon, Feb 20, 2006 at 02:36:42PM +0100, Albe Laurenz wrote:
Dear developers of PostgreSQL!
We (City of Vienna) have many Oracle databases, but plan to use
PostgreSQL for our future database installations as much as possible.
The following idea is inspired by Oracle.
We sometimes need to
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Perhaps you should look into pg_service.conf. It's a configuration file
such that in your connect line you can say:
PQconnect(service=production);
and in the config file you say:
[production]
host=db1
port=5434
dbname=main
It's
On Mon, Feb 20, 2006 at 02:36:42PM +0100, Albe Laurenz wrote:
$ psql -h host -p port -d database .
you'd use something like
$ psql -N dbalias ...
and the client would perform a lookup on the LDAP server and
retrieve host name, port and database name.
I suggest you look at pgpool, which
Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
Perhaps you should look into pg_service.conf. It's a configuration file
such that in your connect line you can say:
PQconnect(service=production);
and in the config file you say:
[production]
host=db1
port=5434
Albe Laurenz wrote:
We sometimes need to move a database from one machine to another
(hardware old/broken, upgrades, etc.). Now whenever a database is
moved to a different computer, all the clients have to address the
database at the new hostname.
A lower-tech solution is:
17 matches
Mail list logo
