Re: Remove last traces of SCM credential auth from libpq? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove last traces of SCM credential auth from libpq?
Date
Msg-id 3774246.1678978185@sss.pgh.pa.us
Whole thread Raw
In response to Remove last traces of SCM credential auth from libpq?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove last traces of SCM credential auth from libpq?  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Re: Remove last traces of SCM credential auth from libpq?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> libpq has kept some code related to the support of authentication with
> SCM credentials for some time now, code dead in the backend since
> 9.1.  Wouldn't it be time to let it go and remove this code entirely,
> erroring in libpq if attempting to connect to a server that supports
> that?

+1.  Since that's only used on Unix-domain sockets, it could only be
useful if you were using current libpq while talking to a pre-9.1
server on the same machine.  That seems fairly unlikely --- and if
you did have to do that, you could still connect, just not with peer
auth.  You'd be suffering other quality-of-life problems too,
because we removed support for such old servers from psql and pg_dump
awhile ago.

> Hard to say if this is actually working these days.

I didn't trace the old discussions, but the commit that removed the
server-side support (be4585b1c) mentions something about portability
issues with that code ... so it's rather likely that it didn't work
anyway.

In addition to the changes here, it looks like you could drop the
configure/meson probes that set HAVE_STRUCT_CMSGCRED.

Also, in pg_fe_sendauth, couldn't you just let the default: case
handle it instead of adding a bespoke error message?  We're not
really expecting that anyone is ever going to hit this, so I'm
not convinced it's worth the translation burden.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: gcc 13 warnings
Next
From: Tom Lane
Date:
Subject: Re: The use of atooid() on non-Oid results