Re: Contrib -- PostgreSQL shared variables

Jonathan,

> The stuff that I contribute is often met with resistence, and that may or
> may not be a good thing, but over the years, things I've said they NEEDED
> to do, have been done and PostgreSQL is better for it.

> Now don't think I'm talking trash to Tom either. These guys do a lot of
> hard work. I have the luxury of working on other projects and noticing the
> sorts of things that are a problem or could be great features. I have
> great respect for them, even if not they for me.

I think you're reading too much into the objections. One of the things that
keeps PostgreSQL fast, accessable, and open to new OSS developers is a high
barrier of entry to new code proposed for the core. A certain minimalism is
called for if we don't want to end up like a Microsoft product, bloated,
self-conflicted, and utterly impenetrable even to its own experts. Often
it's Tom and Peter expressing that minimalism but others would have to were
they to go away (gods forfend).

This means that, for a project to get into the core, any proposer will have to
spend a lot of time convincing the people on this list of its worthiness,
both through lobbying and through code. Thus the very first piece of
criticism you'll see is "Why do we need it?". But you can overcome these
sorts of objections -- others have, as you yourself pointed out.

Unfortunately, /contrib is no better than core in this way as our code gets
larger and mainenance gets harder. I believe our eventual goal is/should be
to *remove* contrib entirely, replacing it with a build environment of
pluggable components which Peter is working on. This will have the
beneficial effect of erasing the difficult-to-cross gap which currently
exists between external (pgFoundry, GBorg, Sourceforge) projects and contrib.
Go Peter!

Also, keep in mind that Tom just completed a 300-hour marathon of reviewing
features for 8.0. I can't imagine that he'll take a positive additude
toward new features of any kind for about a month.

> I think the shared variable module is another one of those things. The
> cost overhead of a single variable implemented as a row is too high,
> especially if you want to update it many times a second.

Question: How will these "system variables" behave regarding transactions?
If I update a system variable and roll back the transaction, does it change
back? Do changes in a running transaction remain invisible until COMMIT?
Excuse me if you've already answered these; I've not caught up on my -hackers
backlog since I broke my foot.

--
Josh Berkus
Aglio Database Solutions
San Francisco