Skip site navigation (1) Skip section navigation (2)

Re: new feature: LDAP database name resolution

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Albe Laurenz <all(at)adv(dot)magwien(dot)gv(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: new feature: LDAP database name resolution
Date: 2006-02-28 17:33:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> 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 are actually interesting?  How much code do we save
>if we use libcurl instead of homegrown LDAP-accessing code?  Does
>libcurl bring in any secondary dependencies, or have limitations of
>its own (thread safety is one obvious point to ask about)?
>Depending on an outside library isn't free, so I think the tradeoff
>has to be considered carefully.

It claims to be thread-safe. It has both synch and asynch APIs - 
fetching something synchronously involves literally a handful of lines 
of code.

There are no dependencies that should bother us - for all our uses they 
would be things we normally use anyway, like openssl and zlib. Plus for 
this purpose openldap, of course. These are all optional.

As for uses, I could well imagine hosting a service map on an internal 
web server, for example. If you want it by property it could even be 
done with a CGI script that gives you just the bit you want.

I'm not hugely dogmatic about it, but it seemed to me that for about the 
same amount of trouble we could provide a much more general mechanism.



In response to

pgsql-hackers by date

Next:From: Mark WoodwardDate: 2006-02-28 17:36:03
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Previous:From: Bruce MomjianDate: 2006-02-28 17:32:38
Subject: Re: Dead Space Map

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group