Re: Password identifiers, protocol aging and SCRAM protocol

On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> # This makefile generates two outputs:
>> #
>> # libpgcommon.a - contains object files with FRONTEND defined,
>> # for use by client application and libraries
>> #
>> # libpgcommon_srv.a - contains object files without FRONTEND
>> defined,
>> # for use only by the backend binaries
>
>
> It claims that libpcommon.a can be used by libraries, but without -fPIC,
> that's a lie.

Yes.

>>> One thing about my current set of patches is that I have begun adding
>>> files from src/common/ to libpq's list of files. As that would be new
>>> I am wondering if I should avoid doing so.
>>
>>
>> Well, it could link source files from there just as easily as from the
>> backend. Not object files, though.
>
>
> I think that's the way to go (and that's what Michael's latest patch did).
> But let's update the comment in the Makefile, explaining that you can also
> copy or symlink source files directly from src/common as needed, for
> instance for shared libraries.

Updating that is a good idea.

> Let's take the opportunity and also move src/backend/libpq/ip.c and md5.c
> into src/common. It would be weird to have sha.c in src/common, but md5.c in
> src/backend/libpq. Looking at ip.c, it could be split into two: some of the
> functions in ip.c are clearly not needed in the client, like enumerating all
> interfaces.

It would be definitely better to do all that before even moving sha.c.
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?
--
Michael