>> I'd like to vote in favor of this patch:
>> http://candle.pha.pa.us/mhonarc/patches2/msg00025.html.
>
>> I know Tom said he didn't really like it, but I'd ask you to
>reconsider
>> that.
>
>The patch is unacceptable as is because (a) it adds a libpq
>configuration parameter that acts differently from all the other ones
>(not supported in connect strings for instance) and (b) it adds no
>documentation for that variable, nor for the server-side variable it
>adds. Doing the libpq parameter in a more thorough fashion is just a
>matter of programming-by-example (grep for CONNECT_TIMEOUT for an
>example) but I for one don't know enough about Kerberos to document
>the thing.

Daniel asked about (a) - I'm not sure if he received an answer, I
couldn't find one at least.
(http://candle.pha.pa.us/mhonarc/patches2/msg00024.html has the question
and some more comments from him). And he offered to write up docs.

Daniel, still up for doing this? If not, I can try to update the patch
to address Toms concerns.

Tom, assuming we fix this, are you fine with the concept? The discussion
back then mentioned the "another way to fail the connection". I think
the gain far overweighs the pain, but it'd be nice to have that
confirmed before more work is committed.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

"Magnus Hagander" <mha@sollentuna.net> writes:
> Tom, assuming we fix this, are you fine with the concept?

Mostly. Should the --with-krb-srvnam configure parameter go away?
Or is it now seen as establishing an installation default? (Either
way implies some documentation work.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match