Re: new feature: LDAP database name resolution

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 particular Windows has a caching
problem there.

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.
- This feature cannot be used with psql or ecpg, right?

Do you think that it is worth the effort for me to look into extending
the
pg_service.conf/PGSYSCONFDIR approach to LDAP (and changing psql to use
it)?

Yours,
Laurenz Albe

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 generate the config file automatically
from another source, either LDAP or something else.

> - This feature cannot be used with psql or ecpg, right?

Well it can since it works with any library that uses libpq, though
it's not immediately obvious. Unfortunatly it appears ecpg doesn't
appear to allow you to specify a connection string, so you have to do
it using the environment variable.

Instead of using a commandline argument to psql you have to do it like
this:

PGSERVICE=test psql

For an ecpg application, setting the PGSERVICE environment variable and
then connecting as DEFAULT should work.

For Perl CBI applications where you specify the connect string
yourself, you can just use "service=test".

> Do you think that it is worth the effort for me to look into extending
> the
> pg_service.conf/PGSYSCONFDIR approach to LDAP (and changing psql to use
> it)?

Given that pg_service.conf is handled by libpq, it would be better to
change it there so all applications connecting to postgres can use it,
not just psql.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

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 long to propagate; in particular Windows has a caching
> problem there.

So even if you specify the TTL of the DNS records to be 60 seconds for
the front end labels you put on your servers, Windows will not refresh
after that period of time, even though it should?

[snip]

> Yours,
> Laurenz Albe
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>

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 file on every
>> client.
>
> Well yes. However, you could generate the config file automatically
> from another source, either LDAP or something else.

this is definitely the best way of doing it. in fact some folks out
there use similar configurations to manager large scale systems
efficiently.

best regards,

hans-jürgen schönig

--
cybertec geschwinde & schönig gmbh
schöngrabern 134, a-2020 hollabrunn
www.cybertec.at