From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: coverage additions |
Date: | 2019-06-06 09:14:45 |
Message-ID: | 20190606091445.GD10729@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 04, 2019 at 04:07:17PM -0400, Alvaro Herrera wrote:
> On 2019-Jun-04, Michael Paquier wrote:
>> On Sat, Jun 01, 2019 at 12:55:47AM -0400, Alvaro Herrera wrote:
>>> Ah, now I remember that I tried this before, but it requires some extra
>>> packages installed in the machine I think, and those create running
>>> services. Did you note that src/backend/libpq does not even list the
>>> gssapi file?
>>
>> Do you mean the header file be-gssapi-common.h?
>
> Actually, I meant be-gssapi-common.c, but I suppose having the file
> appear at all would be dependent on whether the GSSAPI stuff is compiled
> in, which seems to require yet another configure switch that we don't
> have in the coverage machine.
Not sure I still follow.. In src/backend/libpq we have
be-gssapi-common.c and be-gssapi-common.c, both getting added only if
with_gssapi is enabled.
> Which in turn makes me think that perhaps src/include/libpq/libpq.h
> needs some splitting or something, because the be-openssl-common.c file
> does not seem to have a corresponding header ...
Yeah, it seems that there could be ways to split that in a smarter
way.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-06-06 09:36:33 | Re: Fix runtime errors from -fsanitize=undefined |
Previous Message | Masahiko Sawada | 2019-06-06 09:08:25 | Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs) |