Re: security label support, revised

On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
>> On Tue, Sep 28, 2010 at 13:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
>> >> The src/include/catalog/duplicate_oids script reports that 3037 ~
>> >> 3040 are used two or more times.
>> >>
>> >> Though all regression tests finish successfully, should this be
>> >> fixed ?
>> >
>> > Woops.  Thanks for the report, fixed.  I wish we had a regression test
>> > that would catch these mistakes.  It's easy to forget to run this
>> > script.
>>
>> Could we run the script as part of the regression tests? :-)
>>
>> Or if not, could we have the buildfarm run it?
>
> I think it should actually be run as part of the regular build.  Ever
> since I started using git and developing like 10 features at once, and
> other people doing the same, the chances of (hidden) OID conflicts is
> growing immensely.

Injecting nonessential checks into the build process doesn't seem like
a good idea to me. Typing 'make' should just do the build. If you
want to check for breakage, well, that's what 'make check' is for.

Another angle on this problem is that, at least AFAICT, the duplicate
OIDs are completely harmless so long as they are in different
catalogs. And if they are in the same catalog, then initdb will fail
(and shame on you if you don't notice that). Long, long ago
pg_description was indexed just by object-OID, so duplicates would be
a problem, but that hasn't been the case since 2001, and I'm not aware
of anything else that relies on OIDs being globally unique either. So
maybe we should decide that we just don't care about this any more.
It seems a little silly since we're in no danger of running out of
OIDs any time soon, but if there's no practical reason to do it...

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