On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> Because I would like to just change my set of patches to have the SHA >> and the encoding functions in src/backend/libpq instead of src/common, >> and then have pgcrypto be compiled with a link to those files. That's >> a cleaner design btw, more in line with what is done for md5.. > > 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. 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. Here is what I mean: --- a/src/interfaces/libpq/Makefile +++ b/src/interfaces/libpq/Makefile @@ -43,6 +43,14 @@ OBJS += $(filter crypt.o getaddrinfo.o getpeereid.o inet_aton.o open.o system.o OBJS += ip.o md5.o # utils/mb OBJS += encnames.o wchar.o +# common/ +OBJS += encode.o scram-common.o + -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
