Re: Contrib -- PostgreSQL shared variables - Mailing list pgsql-hackers

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