authtype parameter in libpq

Started by Daniel Gustafssonabout 5 years ago5 messageshackers
Jump to latest
#1Daniel Gustafsson
daniel@yesql.se

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/

Attachments:

0001-Remove-defaults-from-authtype-parameter.patchapplication/octet-stream; name=0001-Remove-defaults-from-authtype-parameter.patch; x-unix-mode=0644Download+1-3
#2Peter Eisentraut
peter_e@gmx.net
In reply to: Daniel Gustafsson (#1)
Re: authtype parameter in libpq

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).

#3Daniel Gustafsson
daniel@yesql.se
In reply to: Peter Eisentraut (#2)
Re: authtype parameter in libpq

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/

Attachments:

v2-0001-Remove-deprecated-parameters-authtype-and-pqtty.patchapplication/octet-stream; name=v2-0001-Remove-deprecated-parameters-authtype-and-pqtty.patch; x-unix-mode=0644Download+20-43
#4Peter Eisentraut
peter_e@gmx.net
In reply to: Daniel Gustafsson (#3)
Re: authtype parameter in libpq

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.

#5Peter Eisentraut
peter_e@gmx.net
In reply to: Peter Eisentraut (#4)
Re: authtype parameter in libpq

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