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

From Heikki Linnakangas
Subject Re: Password identifiers, protocol aging and SCRAM protocol
Date
Msg-id 69938195-9c76-8523-0af8-eb718ea5b36e@iki.fi
Whole thread Raw
In response to Re: Password identifiers, protocol aging and SCRAM protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Password identifiers, protocol aging and SCRAM protocol  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 07/22/2016 03:02 AM, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'm confused.  We need that code in both libpq and backend, no?
>>> src/common is the place for stuff of that description.
>
>> Not necessarily. src/interfaces/libpq/Makefile uses a set of files
>> like md5.c which is located in the backend code and directly compiles
>> libpq.so with them, so one possibility would be to do the same for
>> sha.c: locate the file in src/backend/libpq/ and then fetch the file
>> directly when compiling libpq's shared library.
>
> Meh.  That seems like a hack left over from before we had src/common.
>
> Having said that, src/interfaces/libpq/ does have some special
> requirements, because it needs the code compiled with -fpic (on most
> hardware), which means it can't just use the client-side libpgcommon.a
> builds.  So maybe it's not worth improving this.

src/common/Makefile says:

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

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

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.

- Heikki




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Anyone want to update our Windows timezone map?
Next
From: Aleksander Alekseev
Date:
Subject: Re: [Patch] New psql prompt substitution %r (m = master, r = replica)