Re: Oid registry

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Oid registry
Date: 2012-09-27 20:02:45
Message-ID: CA+TgmoafZTaHfRTvDE0PKi3YxHYfYWqeToP3oQq9BC5e84a7Ww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> I'm not sure that's a way we really want to go down. How do we define which
> third party vendors would get to reserve oids? And how many? And under what
> other potential terms?
>
> Seems like we'd set ourselves up for endless discussions and bike
> shedding...

Not really. I'm only proposing that it would be nice to have a block
of OIDs that core agrees not to assign for any other purpose, not that
we dole out specific ones to specific companies. There's no reason
why, for example, EnterpriseDB's fork can't use OIDs from the same
reserved block as PostgreSQL-XC's fork or Greenplum's fork or Aster
Data's fork - those are all distinct projects. All might need private
OIDs but they can all come from the same range because the code bases
don't mingle.

That having been said, we've gotten this far without having any
terrible trouble about this, so maybe it's not worth worrying about.
It's a nice-to-have, not a big deal.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-09-27 20:06:16 Re: psql, remove include of psqlscan.c
Previous Message Tom Lane 2012-09-27 19:37:00 Re: psql, remove include of psqlscan.c