Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group