Re: Oid registry

On Mon, Sep 24, 2012 at 8:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So, yeah, we could reserve a couple hundred OIDs for a scheme like this
> and (probably) not regret it later.  But a couple thousand would scare
> me ... and I'm not exactly convinced that a couple hundred is enough,
> if there's any demand out there at all.

I think some kind of way to compose extension objects -- this includes
and goes beyond just the things in pg_type, but operators and so on --
will have great impact on Postgres' power without making the community
effort unscalable.  I think PostGIS is the largest success by this
metric -- although certain requirements spill back into pgsql-hackers,
it's a pretty huge island of functionality out there that neatly
progresses on its own without coordination.  That's fantastic.

I am fairly certain that if some form of in-line extensions were
supported, we would see people building smaller extensions that use
many little types (such as composites) relying on other extensions to
do things or manage certain tables, increasing convenience overall.

Things like the JSON data type (in spite of my own opinion that it
should be added) are a highly useful concession.  Yet, it is still a
concession that extensions simply cannot be as close to good as a core
data type when it comes to the ability to compose.  The gap between
pre-JSON-in-the-standard-library in Python, Ruby, et al and
post-JSON-in-stdlib was much smaller.  Even for statically typed
languages -- like Java -- the only central-registries that exist are
mostly for the convenience of distribution and deployment, not as the
means of composition, and I think that is a good thing.

However, an IANA-style OID registry I find pretty un-compelling. Is
there no way we can use symbols, the type system, and invalidation
messages to a client to do this?  I feel like there is a way we can,
and it is probably worth it to minimize coordination among extension
authors and enabling smaller extensions.

If reserved OID ranges for extensions are to become a thing, I think
the right scope would be to presume that these extensions are not
bundled with Postgres, but practically, whoever uses that space is
probably going to have to be the kind of person who would correspond
with -hackers.  Ad-hoc composition among small or live-and-die-fast
user-space libraries (that are written in trusted languages, for
example) are out, which is kind of a bummer for what I think plv8 can
enable.

-- 
fdr