Horton

Thread

Commits

  1. libpq: Remove deprecated connection parameters authtype and tty

  2. From: Phil Thompson <phil@river-bank.demon.co.uk>

  1. authtype parameter in libpq

    Daniel Gustafsson <daniel@yesql.se> — 2021-02-26T20:02:11Z

    When looking at disallowing SSL compression I found the parameter "authtype"
which was deprecated in commit d5bbe2aca55bc8 on January 26 1998.  While I do
think there is a case to be made for the backwards compatibility having run its
course on this one, shouldn't we at least remove the environment variable and
default compiled fallback for it to save us a getenv call when filling in the
option defaults?

--
Daniel Gustafsson		https://vmware.com/

  2. Re: authtype parameter in libpq

    Peter Eisentraut <peter@eisentraut.org> — 2021-03-03T13:47:38Z

    On 26.02.21 21:02, Daniel Gustafsson wrote:
> When looking at disallowing SSL compression I found the parameter "authtype"
> which was deprecated in commit d5bbe2aca55bc8 on January 26 1998.  While I do
> think there is a case to be made for the backwards compatibility having run its
> course on this one, shouldn't we at least remove the environment variable and
> default compiled fallback for it to save us a getenv call when filling in the
> option defaults?

The argument of avoiding unnecessary getenv() calls is sensible.  PGTTY 
should get the same treatment.

But I tend to think we should remove them both altogether (modulo ABI 
and API preservation).

  3. Re: authtype parameter in libpq

    Daniel Gustafsson <daniel@yesql.se> — 2021-03-04T15:06:36Z

    > On 3 Mar 2021, at 14:47, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
> On 26.02.21 21:02, Daniel Gustafsson wrote:
>> When looking at disallowing SSL compression I found the parameter "authtype"
>> which was deprecated in commit d5bbe2aca55bc8 on January 26 1998.  While I do
>> think there is a case to be made for the backwards compatibility having run its
>> course on this one, shouldn't we at least remove the environment variable and
>> default compiled fallback for it to save us a getenv call when filling in the
>> option defaults?
> 
> The argument of avoiding unnecessary getenv() calls is sensible.  PGTTY should get the same treatment.

The reason I left PGTTY alone is that we still have a way to extract the value
set via PQtty(), so removing one or two ways of setting it while at the same
time allowing the value to be read back seemed inconsistent regardless of its
obsolescence.

authtype is completely dead in terms of reading back the value, to the point of
it being a memleak if it indeed was found in as an environment variable.

> But I tend to think we should remove them both altogether (modulo ABI and API preservation).

No disagreement from me, the attached takes a stab at that to get an idea what
it would look like.  PQtty is left to maintain API stability but the parameters
are removed from the conn object as thats internal to libpq.

--
Daniel Gustafsson		https://vmware.com/

  4. Re: authtype parameter in libpq

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2021-03-08T09:57:56Z

    On 04.03.21 16:06, Daniel Gustafsson wrote:
> authtype is completely dead in terms of reading back the value, to the point of
> it being a memleak if it indeed was found in as an environment variable.
> 
>> But I tend to think we should remove them both altogether (modulo ABI and API preservation).
> 
> No disagreement from me, the attached takes a stab at that to get an idea what
> it would look like.  PQtty is left to maintain API stability but the parameters
> are removed from the conn object as thats internal to libpq.

This looks like this right idea to me.

  5. Re: authtype parameter in libpq

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2021-03-09T14:51:41Z

    On 08.03.21 10:57, Peter Eisentraut wrote:
> On 04.03.21 16:06, Daniel Gustafsson wrote:
>> authtype is completely dead in terms of reading back the value, to the 
>> point of
>> it being a memleak if it indeed was found in as an environment variable.
>>
>>> But I tend to think we should remove them both altogether (modulo ABI 
>>> and API preservation).
>>
>> No disagreement from me, the attached takes a stab at that to get an 
>> idea what
>> it would look like.  PQtty is left to maintain API stability but the 
>> parameters
>> are removed from the conn object as thats internal to libpq.
> 
> This looks like this right idea to me.

committed, with some tweaks