September 10th, 2003, 11:44 AM
lol X 2
Anyway, aside from missing discussion of domains, the "PostgreSQL" book looks like one of the better ones out there. Still, the "perfect" book on PostgreSQL doesn't exist yet.
And to be fair, domains in PostgreSQL will be a much more complete feature when PostgreSQL 7.4 comes out.
FYI, the things I have personally found most PostgreSQL books to be deficient in are:
1. Very over-simplified discussion of the Postgres "rules" system, which allows for query rewriting (think of the SQL equivalent to Apache's mod_rewrite). The most important area of this is in the use of rules to make views updatable.
2. The structure of most of the example databases are quite simple. Some complex examples might be helpful.
3. Not enough discussion on the overall importance of integrity constraints in general. This applies to such things as table design, CHECK constraints, use of NULL/Not NULL, referential integrity, and (for the future) the use of domains to tie constraints to a type alias.
4. Not enough time spent on the conceptual importance of the relational data model in general, and how it applies to SQL. (note: SQL is not completely a relational language, but it is primarily based on relational principals). For example, normalization is usually treated as an afterthought.
And again to be fair most of this kind of material is missing from just about any recent book on database systems. For a real book on understanding the "why" of modern database systems, you should read something like "Database Design for Mere Mortals" (very easy intro to these concepts), or "Introduction to Database Systems", by C.J. Date (at the opposite end of the spectrum, this is more of a conceptual book for true software engineers).
September 10th, 2003, 12:05 PM
damn you rycamor! making me buy more books!
I appreciate your comments.
does postgres allow you to write stored proceedures in php? or do you have to use perl, C or another language?
September 18th, 2003, 01:38 PM
I am a fond user of postgreSQL and find it to be useful and full featured. For different clients, I work in postgres and mysql, and my original database background is from Oracle.
However, it drives me CRAZY to try to find things in the postgres documentation. For example, the export/import via text file problem is something we all need to do, and frequently. If I search the postgres documentation for the exact command for it, I try things like "load data text file" or "load data infile" (I seem to remember mysql commands better ) and get nowhere. I have to remember that the command is _copy_ to go in and pg_dump to go out.
I keep having the same problem with formatting dates. I always try to look up dateformat, but the actual page describing the function I want ( to_char) doesn't come up and is hard to find.
It doesn't help that the search command shows the header info for each document, which is almost identical for each result.
I think that postgreSQL would have better acceptance if the documentation search engine had some of the equivalent function names tied to the correct pages. It's a great database, but it doesn't matter how great it is if you can't remember how to dump a text file from it.
If someone out there would plug the data in, I would even be happy to start developing a list.
September 18th, 2003, 02:05 PM
There are a couple of people working on better documentation searching features. I admit that the present methods are horrible. Really, I wish the PostgreSQL team would enlist the help of the PHP documentation team. IMHO, the PHP online documentation is one of the best designs I have found anywhere.
Hmm... now that I mention it, I am reminded that the source for the PHP.net documentation website is completely available. At the bottom of each page there is a "show source" link.
Time to do some source code browsing... What do you think, elef?
PostgreSQL allows you to write stored procedures in more languages than you would believe, and they are continually adding to the pool of procedural language modules. Yes, there is work being done on a PHP procedural module for PostgreSQL, although it is still Beta quality.
Also in beta for procedural modules are Java and PL/R (for heavy-duty statistics and math), and even Ruby. The existing languages you can use for procedures are:
- SQL (yes, plain SQL )
- PL/PgSQL -- the "official" procedural language for PostgreSQL
- C (I think somewhere there is a C++ port also)
September 18th, 2003, 03:12 PM
Sorry to come to the party late, but last week was my honeymoon so I didn't find this thread until now
It's true the docs could use some work, but I think they've been getting better (or maybe I'm just used searching through them now). If it were possible to get it up to how PHP's is done that would be awesome.
Regarding books, I've been looking into Postgres books myself but with the rapid development being done (thx PG team ) it's not really worth it. It's probably more worth your money to pick up general SQL books, or more importantly, relational theory books (see rycamor's recommendations in this and past various threads in this forum and the general DB forum) at the moment.
I'd like to see a bit more in PG books on the following as well:
-More in depth review of syntax and capabilities strengths/weaknesses of the procedural languages available
-A good tweak guide for performance since anyone who's worked with PG knows the default setup is made for compatibility rather than speed. The tweak guide by Josh Berkus and Shridhar Daithankar is a great leap forward over what's been available previously, but I'd like to see one that's more newb friendly and with more examples so that migraters from mysql don't immediately look at initial benchmarks and get frightened off.
BTW, the PG mailing lists are another great resource besides these forums. They're very open and helpful and I've hardly ever seen a flame.
PostgreSQL, it's what's for dinner...
September 18th, 2003, 03:27 PM
Congrats, bcyde .
Yes, in general presentational/informational is one of the biggest needs of the PostgreSQL project. MySQL has done quite well in this area, but really, PostgreSQL is such a large-scale, complex project that it is much harder to get readable documentation together. I would estimate that, with all the functionality+procedural languages, the potential PostgreSQL documentation should be almost 5X the MySQL documentation.
Point is, it's a large undertaking to make quality information available for PostgreSQL. Probably an area where the PG project could use more help than any other (hint, hint...).