Joshua D. Drake wrote:
> On Mon, 2009-03-09 at 19:45 -0400, Tom Lane wrote:
>> Hannu Krosing <hannu@2ndQuadrant.com> writes:
>>> Can't it be kept separately maintained release for a version or two, so
>>> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
>>> easy way to compare both correctness and performance ?
>> Actually, KaiGai-san has been distributing a patched SEPostgres on
>> Fedora for awhile already (and it's been rather a pain in the neck
>> I fear to keep it in sync with the regular distribution). One thing
>> I would love to know is how many people are actually using that, but
>> AFAIK there's no good way to find out.
>
> To point out the obvious, we are in a quandary here. Nobody argues the
> feature would be interesting and although I don't have use for it I
> could see where some people would. I also see where it would open doors
> for us.
>
> Is there any possibility of having it be enabled at compile time? The
> default would be know but those distributions that would like to make
> use of it could?
It was the design a half year ago, but Bruce suggested me a certain
feature should not be enabled/disabled by compile time options,
except for library/platform dependency. In addition, he also suggested
a feature should be turned on/off by configuration option, because of
it enables to distribute a single binary for more wider users.
SE-PostgreSQL need the libselinux to communicate the in-kernel SELinux.
So, --enable-selinux is necessary on compile time, it is fair enough.
If we omit it, all the sepgsqlXXXX() invocations are replaced by empty
macros.
If we compile it with --enable-selinux, it has two working modes
controled by a guc option: sepostgresql (bool).
If it is disabled, all the sepgsqlXXXX() invocations returns at
the head of themself without doing anything.
I believe this behavior follows the previous suggestion.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>