Re: Password identifiers, protocol aging and SCRAM protocol - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Password identifiers, protocol aging and SCRAM protocol
Date
Msg-id CAB7nPqS9sWG5e6taBAo8O55rsptg-WL2-TAwVTzetiTicYdekw@mail.gmail.com
Whole thread Raw
In response to Re: Password identifiers, protocol aging and SCRAM protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Password identifiers, protocol aging and SCRAM protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On Fri, Aug 19, 2016 at 1:51 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 08/18/2016 03:45 PM, Michael Paquier wrote:
>>
>> On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas <hlinnaka@iki.fi>
>> wrote:
>> For the current ip.c, I don't have a better idea than putting in
>> src/common/ip.c the set of routines used by both the frontend and
>> backend, and have fe_ip.c the new file that has the frontend-only
>> things. Need a patch?
>
>
> Yes, please. I don't think there's anything there that's needed by only the
> frontend, but some of the functions are needed by only the backend. So I
> think we'll end up with src/common/ip.c, and src/backend/libpq/be-ip.c. (Not
> sure about those names, pick something that makes sense, given what's left
> in the files.)

OK, so let's do that first correctly. Attached are two patches:
- 0001 moves md5 to src/common
- 0002 that does the same for ip.c.
By the way, it seems to me that having be-ip.c is not that much worth
it. I am noticing that only pg_range_sockaddr could be marked as
backend-only. pg_foreach_ifaddr is being used as well by
tools/ifaddrs/, and this one calls as well pg_sockaddr_cidr_mask. Or
is there still some utility in having src/tools/ifaddrs? If not we
could move pg_sockaddr_cidr_mask and pg_foreach_ifaddr to be
backend-only. With pg_range_sockaddr that would make half the routines
to be marked as backend-only.

I have not rebased the whole series yet of SCRAM... I'll do that after
we agree on those two patches with the two commits you have already
done cleaned up of course (thanks btw for those ones!).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: Re: Slowness of extended protocol
Next
From: Tatsuo Ishii
Date:
Subject: Re: Slowness of extended protocol