--- vincent <vinny@xxxxxxxxx> wrote:
> > On Wed, 30 Jan 2008 11:27:20 +0000
> > Gregory Stark <stark@xxxxxxxxxxxxxxxx> wrote:
> >
> > BTW examples are a sort of specification too. I wouldn't
> > underestimate their more formal value. So I think they should be
> part
> > of *the* reference documentation with example output as well.
> > They shouldn't be of the kind "how-to" but of the kind "you can't
> > push the syntax further and this is what you'd expect as an
> output".
>
> In the manual yes, but I think there's definately a need for a
> howto
> document, something that demonstrates how to handle typical
> database
> functionality in PgSQL. Many of the people I've convinced to start
> using
> PostgeSQL spend the first week or so asking me questions on how to
> do
> basic things in PostgreSQL. When I say that there's a manual, the
> complaint usually is what I've noticed myself: the manual is great
> for
> looking up individual facts, but your problem may consist of 15
> facts and
> it's up to you to connect the dots.
>
More documentation would be nice, but surely it's more down to
getting the type of user base that write your average "how to" books?
The O'Reilly books seem to cover postgres quite nicely, however I've
only had a flick through in shops.
One thing's for sure, 2 months ago I signed up to the most common
postgresql and m*sql lists when I was trying to decide what was best
for our backend. At the time m*sql was my 1st choice, and it took me
less than a day to drop those toys in the street and decide
postgresql was the way forward.
___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
---------------------------(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
match
