Re: PostgreSQL Service Name Enhancement - Wildcard support for LDAP/DNS lookup - Mailing list pgsql-hackers
From | Doyle, Bryan |
---|---|
Subject | Re: PostgreSQL Service Name Enhancement - Wildcard support for LDAP/DNS lookup |
Date | |
Msg-id | 0A73D178EDA861479B09451CE35AB56002B687C0F0@GSCMAMP29EX.firmwide.corp.gs.com Whole thread Raw |
In response to | Re: PostgreSQL Service Name Enhancement - Wildcard support for LDAP/DNS lookup (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: PostgreSQL Service Name Enhancement - Wildcard
support for LDAP/DNS lookup
|
List | 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, butit should certainly be considered. I can see where someone may want to have a different LDAP/DNS domain or something likethat 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 (seebelow 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 notspecified in the connection string/connection parameters at all, I would propose that this wildcard entry not match (evenif service names are processed first) and normal processing proceed. As a comparable, the '%' in a like statement doesn'tmatch a NULL after all. I don't think having a blank replacement value would make much sense either. Please informme 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 itexclusively once implemented. I would like to look up all service name entries from a single LDAP location if a previousentry in the file does not short circuit the match. To do this, I am explicitly looking to use a [%] entry in ourservice name file - the prefix requirement is not consistent with our environmental requirements. The service name fileis a client construct that can be overridden by the caller if they desire, but keep in mind that this type of featureis targeted for controlled/managed environments. * Adding additional processing logic for 'myserver-%' would only make this more flexible for other use cases and would certainlymeet the goals of this proposal, so I am fine including it in scope if the [%] is also allowed per above. When theseother wildcard w/ prefix entries can match above the general [%] entry, it could be compelling (see my first email regardingentry order considerations). Those not wanting the [%] could choose to not implement it and stick to something closerto 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/lookupand then [%] is also located further down? ** Without additional discussion, I would assume that it would attempt a connection for consistency. Again, people can chooseto not use both features together. Another option would be to somehow introduce a "stop processing" flag in the serviceentries 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
pgsql-hackers by date: