Our new book PostgreSQL: Up and Running is officially out. It's available in hard-copy and e-Book version directly from O'Reilly,
Safari Books Online and available from Amazon in Kindle store. It should be available in hard-copy within the next week or so from other distributors.
Sadly we won't be attending OSCON this year, but there are several PostgreSQL talks going on. If you are speaking at a talk or other PostgreSQL related get together, and would like
to give out some free coupons of our book or get a free e-book copy for yourself to see if it's worth effort mentioning, please send us an e-mail: lr at pcorp.us .
Our main focus in writing the book is demonstrating features that make PostgreSQL uniquely poised for newer kinds of workflows with particular focus on PostgreSQL 9.1 and 9.2.
Part of the reason for this focus is our roots and that we wanted to write a short book to get a feel for the audience. We started to use PostgreSQL in 2001 because of
PostGIS, but were still predominantly SQL Server programmers. At the time SQL Server did not have a spatial component that integrated seamlessly with SQL.
As die-hard SQLers, PostGIS really turned us on. As years went by, we began to use PostgreSQL
not just for our spatial apps, but predominantly non-spatial ones as well that had heavy reporting needs and that we had a choice of platform.
So we came for PostGIS but stayed because of all the other neat features PostgreSQL had that we found lacking in SQL Server. Three off the bat
are arrays, regular expressions, and choice of procedural languages. Most other books on the market just treat PostgreSQL like it's any other relational database.
In a sense that's good because it demonstrates
that using PostgreSQL does not require a steep learning curve if you've used another relational database. We didn't spend as much time on these common features as we'd like to
in the book because it's a short book and we figure most users familiar with relational databases
are quite knowledgeable of common features from other experience. It's true that a lot of people coming to PostgreSQL are looking for cost savings,
ACID compliance, cross-platform support and decent speed
, but as PostgreSQL increases in speed, ease of features, and unique features, we think we'll be seeing more people migrating
just because its simply better than any other databases
for the new kinds of workflows we are seeing today -- e.g. BigData analysis, integration with other datasources, leveraging of domain specific languages in a more seamless way with data.
So what's that creature on the cover? It's an elephant shrew (sengi) and is neither an elephant nor a shrew, but closest in ancestry to the elephant, sea cow, and aardvark.
It is only found
in Africa (mostly East Africa around Kenya) and in zoos. It gets its name from its unusually long nose which it uses for sniffing out insect prey and keeping tabs on its mate. It has some other unusual habits:
it's a trail blazer building trails it uses to scout insect prey and also builds escape routes on the trail it memorizes to escape from predators. It's monogamous, but prefers to keep separate quarters from its mate. Males
will chase off other males and females will chase off other females. It's fast and can usually out-run its predators.
The link does work, but this is the actual Kindle e-book listing: http://www.amazon.com/dp/B008IGIKY6/ref=nosim/175-6170630-3323238?tag=postgresonline-20&linkCode=sb1&camp=212353&creative=380549 . In a sidebox, it says: "This title is not available for customers from your location in:
Europe..." Might get it from O'Reilly's, but I wanted to read the Kindle sample first.
I've tried that when I first got the message some time ago with a different book. Only amazon.com sells e-book internationally, the .co.uk, .it and other 'localised' domains sell them only to people in that particular country.
It's probably a restriction imposed by the published, probably for no good reason (might be a default setting at Amazon).
One example for incorrect query output is in the section "Time Zones: What It Is and What It Isn’t". On the same topic you state that "PostgreSQL support for temporal data is unparalleled." What does that mean really? Do you say Oracle for example doesn't have as good support as PostgreSQL? In the section you don't give no exploitation whatsoever. IMO a developer should either make this conclusion for himself or you should give your arguments.
Also when you describe in "SQL views" you start to wildly use the term "rule" but in the book so far there is no notion of what a "rule" might be. I know what a rule is but this doesn't mean a new PostgreSQL user is familiar with that.
In a longer book we would go more into detail of why we think PostgreSQL temporal data support is unparalleled. For one the 9.2 will have temporal range support (which we mention in the second sentence) and has period extension in prior versions. I don't think this is a feature Oracle has. Any rate that is not a mistake but an opinionated understatement at best.
Regarding the query example where you saw incorrect output, which one is that? There are a couple examples in that section. One of them we did say you'd get a different answer depending on what your default time zone is and that was intentional. If it is truly a mistake, we would like to correct. Keep in mind any corrections we make if you ordered the e-Book you will get them fairly quickly.
Good point on SQL views. That we should probably amend. We did provide a link to an example of rules and how they are used though. We tried to play down rules (evidentally not well) and even didn't give an example, since the preferred way from 9.1+ is to use triggers which we do provide two examples of (one for views and one for a table).