From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Kohei Kaigai <Kohei(dot)Kaigai(at)emea(dot)nec(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.1] sepgsql - userspace access vector cache |
Date: | 2011-08-19 15:26:04 |
Message-ID: | 8206.1313767564@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-08-19 15:32:49 | Re: [v9.1] sepgsql - userspace access vector cache |
Previous Message | Kohei Kaigai | 2011-08-19 15:26:01 | Re: [v9.1] sepgsql - userspace access vector cache |