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 lda
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 c
> 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
> pg
"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,
>
>>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
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.
-
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 na
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 pg_services.con
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 fi
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 lon
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 gen
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 par
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:
http://
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
dbn
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, whi
* 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=ma
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 n
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 move a database from one machine to another
(hardware old/broken, upg
18 matches
Mail list logo
