On Friday 04 August 2006 21:19, Tom Lane wrote:
> Rick Gigger <[EMAIL PROTECTED]> writes:
> > So if you define "major features" as class A features.  In this case
> > major doesn't mean important or useful or difficult to implement,
> > just that they are the sort of features that one might be told to
> > look for when shopping for a database.  So in terms of marketing
> > PITR, two phase commit,  WIN32 support were very much "major" features.
> You have a point: 8.0 and 8.1 had much more buzzword-compliant stuff
> added.  The truth of the matter is that a lot of that stuff was pretty
> rough-edged in actual use, and now we're starting to smooth it out and
> make it more readily usable.  So in terms of *usable* PITR etc we're
> only now getting there with 8.2.  But that's not a bullet point that
> impresses PHBs.
> > That being said I think that two of the not-yet-reviewed features are
> > just as "major" as the "major" features from the past two releases.
> >
> > 1) updatable views - I won't really use this but it just seems like
> > one of those features that people use when doing rdbms features
> > comparison charts.
> Agreed, if this gets in it will be a Real Biggie.  I de-emphasized it
> in my list because I haven't looked at the patch yet and so have no
> idea whether it's any good, but I fully agree it's a PHB-worthy
> bullet point if it works.

Hmm.. I would de-emphasize it because it doesn't give us give us anything we 
couldn't do before; and really what we can do now is way above most database 

> > 2) restartable recovery (allow checkpoints for a hot-standby server)
> > - Having the ability to have a hot standby database is a HUGE feature
> > in my book.
> Again, we claimed to have hot standby in 8.1, and we sort of did, it
> just didn't work all that nicely.  This will file down one seriously
> rough edge, but is that a good marketing bullet point?  Probably not.

So, the things I hear most non-postgresql people complain about wrt postgresql 

no full text indexing built in
no replication built in
no stored procedures (with a mix of wanting in db cron facility) 
the planner is not smart enough (with a mix of wanting hints)
vacuum leads to unpredictable performance

Of that list, they could probably all be turned into nice marketing points 
(though #4 is pretty nebulous), though I don't see any of them getting 
resolved anytime soon. 

Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to