| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Raising our compiler requirements for 9.6 |
| Date: | 2015-08-07 17:11:52 |
| Message-ID: | 20150807171152.GC4916@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
> It may not be included from any IN CORE frontend code, but that is not
> the same thing as saying it's not included from any frontend code at
> all. For example, EDB has code that includes namespace.h in frontend
> code. That compiled before this commit; now it doesn't.
Nothing in namespace.h seems to be of any possible use for frontend
code. If there were possible use-cases I'd be inclined to agree, but you
obvoiusly can't use any of the functions, the structs and the guc make
no sense either. So I really don't why we should cater for that?
I think the likelihood of actually breaking correct working extension
code that uses namespace.h that'd be broken if we removed lock.h from
namespace.h is an order of magnitude bigger than the possible impact on
frontend code.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-08-07 17:17:32 | Re: Raising our compiler requirements for 9.6 |
| Previous Message | Jesper Pedersen | 2015-08-07 16:49:20 | Re: Reduce ProcArrayLock contention |