Re: [v9.1] sepgsql - userspace access vector cache

On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On further review, if the initial configure was done without
>> --with-libxml, xml2 is doomed anyway.
>
> True, but it's still possible to build a shlib that will then not work.
> I just did, after manually supplying the right -I switch:
>
> make PROFILE=-I/usr/include/libxml2
>
> Now admittedly a clueless person would be unlikely to know to do that,
> but if his libxml installation were arranged so that no special -I
> switch was needed (unlike the Fedora packaging), it'd be more likely
> that this could happen.
>
>> This probably explains why no one's complained about this before, and
>> I think the appropriate fix is to change just sepgsql.  I would like
>> to back-patch that (one-line) change into 9.1 as well, to eliminate
>> this as a foot-gun for anyone who may be packaging that module for the
>> first time.
>
> No objection to fixing or backpatching this, but I'm not seeing the
> argument for treating this module differently from contrib/xml2.  If you
> believe that someone will try to manually build in contrib/sepgsql after
> having failed to configure correctly, why do you not believe that for
> xml2?

Because I screwed it up accidentally for sepgsql, and I can't screw it
up for xml2 on purpose even after working fairly hard. Even after
shoving in the necessary -I switch (through a slightly different
mechanism than the one you just proposed), it still won't link,
whether -lxml2 is on the command-line or not.

That having been said, I don't mind changing them both symmetrically;
I'm just convinced that there's any benefit. However, if you think
that way is more future-proof or that I might be overlooking some
scenario, fine! It won't hurt anything.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company