From: | "Doyle, Bryan" <Bryan(dot)Doyle(at)gs(dot)com> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Service Name Enhancement - Wildcard support for LDAP/DNS lookup |
Date: | 2014-10-26 02:51:50 |
Message-ID: | 0A73D178EDA861479B09451CE35AB56002B687C0F0@GSCMAMP29EX.firmwide.corp.gs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
I believe there are two main concerns that you raise, addressed below:
First:
> It needs to be a more constrained syntax.
> One possibility is to insist that the wildcard be only a part
> of the name string, eg
>
> [myservers-%]
> host=%.domain.com
> port=5433
> user=admin
* This counter-proposal is getting closer to the more complex matching requirements that I was attempting to de-scope, but it should certainly be considered. I can see where someone may want to have a different LDAP/DNS domain or something like that through prefix convention, though we would likely want to restrict to one "%" symbol in the service definition, yes? I am fine with including this capability in the patch, provided the general [%] case is still supported (see below for expanded reasons).
Second:
> since we check service names
> before other possibilities such as host/database names, the entry would
> then proceed to capture every possible connection request
* I should have explicitly covered the case where no service name is provided at connection time - If a service name is not specified in the connection string/connection parameters at all, I would propose that this wildcard entry not match (even if service names are processed first) and normal processing proceed. As a comparable, the '%' in a like statement doesn't match a NULL after all. I don't think having a blank replacement value would make much sense either. Please inform me if I am not addressing some part of your concern with this mindset.
Some additional comments:
* It is in fact is desirable for us (and likely others) to capture all service names in one entry; I expect to utilize it exclusively once implemented. I would like to look up all service name entries from a single LDAP location if a previous entry in the file does not short circuit the match. To do this, I am explicitly looking to use a [%] entry in our service name file - the prefix requirement is not consistent with our environmental requirements. The service name file is a client construct that can be overridden by the caller if they desire, but keep in mind that this type of feature is targeted for controlled/managed environments.
* Adding additional processing logic for 'myserver-%' would only make this more flexible for other use cases and would certainly meet the goals of this proposal, so I am fine including it in scope if the [%] is also allowed per above. When these other wildcard w/ prefix entries can match above the general [%] entry, it could be compelling (see my first email regarding entry order considerations). Those not wanting the [%] could choose to not implement it and stick to something closer to the prefix approach you have in mind.
Summary of Open Questions:
* (From Above) For prefix wildcards, OK to restrict to one % replacement?
* Do the above points address initial concerns regarding service names being processed before host/db names?
* If both prefix/non-prefix are allowed, what should be the behavior for cases where [prefix-%] matches and fails to connect/lookup and then [%] is also located further down?
** Without additional discussion, I would assume that it would attempt a connection for consistency. Again, people can choose to not use both features together. Another option would be to somehow introduce a "stop processing" flag in the service entries on connection/lookup failures, which may be generally useful even when wild cards are not in use.
Thanks for the reply and your thoughts on this proposal so far. I am looking forward to the continued conversation.
Bryan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-10-26 04:34:44 | Re: make pg_controldata accept "-D dirname" |
Previous Message | Tom Lane | 2014-10-26 02:40:12 | Re: Getting rid of "accept incoming network connections" prompts on OS X |