On Mon, Sep 24, 2012 at 8:21 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
