Re: Allow change of kerberos service name without recompilation

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Daniel Ahlin <dah(at)pdc(dot)kth(dot)se> 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