No one has ever asked for a kerberos service name different from "postgres". Unless someone else says this is a useful feature, I think we are better off leaving our code unchanged.
Kerberos is pretty complicated so adding another configuration options isn't always a good idea. --------------------------------------------------------------------------- Daniel Ahlin wrote: > Tom Lane <[EMAIL PROTECTED]> writes: > > > Daniel Ahlin <[EMAIL PROTECTED]> writes: > > > This is a two part patch against 7.4.5 implementing the option of > > > configuring what is now set using the #defined constant PG_KRB_SRVNAM > > > (the name of the service part of the kerberos principal the server > > > uses). > > > > Is this a good idea? Offhand it just seems like another way for a > > client to fail to establish communication with the server :-(. > > Certainly, in some sense it will give you more rope to hang > yourself. However, please consider that as of now the service name is > a compile time option, easily changable via configure option. > > That means that if you want a non-default setting of this, you have to > use a backend and an interface compiled using the same or identical > compilation settings. That, in turn, means that if you provide users > with precompiled versions of the software, you have to provide them > with one version for each servicename (which is of course just silly). > > What it boils down to is actually whether you think that differing > servicenames should be allowed. That is, if you can see any valid use > cases for it. I know there exist such, but it may only be in my > particular setting. > > (From my perspective it is very much the same as providing a way to > easily configure which port number to use. The situations where the > need to change default behaviour is also probably similar.) > > > In any case, the patch is quite shy of documentation... > > I can provide more documentation if you feel that it is lacking (btw, > do you mean usage- or code documentation or both). > > Then again, since the patchset is small and nonintrusive I have no > vested intrest in getting the patch included (it will be easy enough > to keep updated on site). I know I need it, you are welcome to use it > if you want to. > > Either way, I would like to ask if the way the client handles the > retrieval of the optional value (by explicit getenv in fe-auth.c) is > the approved method or not. Perhaps something like what is found for > PGHOST in fe-connect.c, would be better? If so, would it break the > interfaces for the other languages using fe-connect? > > Regards > Daniel Ahlin > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly