Thread: Book nearing final form
I have been told by the publisher that most changes to the book must be
done by next week.
The book is at:
http://www.postgresql.org/docs/awbook.html
Again, many thanks to those that have supplied suggestions for the book.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wed, 7 Jun 2000, Bruce Momjian wrote: > I have been told by the publisher that most changes to the book must be > done by next week. Bruce, I take it that copies of your book signed by yourself (and any other developers who happen to be interested :-) will be available as a value-add on the postgres site. Cheers! (Relax...have a homebrew) Neil
> On Wed, 7 Jun 2000, Bruce Momjian wrote: > > > I have been told by the publisher that most changes to the book must be > > done by next week. > > > Bruce, > > I take it that copies of your book signed by yourself (and any other > developers who happen to be interested :-) will be available as a > value-add on the postgres site. I hadn't thought that far in advance yet. I am CC'ing core for a comment. :-) -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> At 06:28 PM 07-06-2000 -0400, Bruce Momjian wrote: > >I have been told by the publisher that most changes to the book must be > >done by next week. > > > >The book is at: > > > > http://www.postgresql.org/docs/awbook.html > > > >Again, many thanks to those that have supplied suggestions for the book. > > More "typical usage" examples on commands would be helpful. For example the > cluster command may need a typical usage example. Not everyone can parse > man pages and understand the differences with stuff being between <> and [] > and {} so on... Typical usage examples can help the majority actually get > things done. CLUSTER has limitations currently so I don't want people running it without reading the manual. > > Also a LIMITS section/appendix would be very useful. This should list stuff > like limits on tuples, queries, names, fields, data types, number of tables > (theoretical and practical), number of indexes, and so on. It can be rather > misleading to say that "text" has no limit and only when people bump into > the tuple limit, we tell them of the infamous 8KB row/tuple limit. > Naturally this would be out of date soon, but that just sets the stage for > the 2nd edition ;). That is in the FAQ. That way, then can look at the current version to see the current values. FYI, 8k limit is going away in 7.1, and the book will be out after 7.1 is released. > > An example for "create user with password" would be good too - since the > web example was unclear/problematic the last time I checked - I had to do > some trial an error. Has to be associated with pg_hba.conf. Too complicated. > > Also another thing should be made clear: > > Stuff like vacuumdb, createdb etc are basically scripts, whereas the actual > commands are vacuum, create database and so on. A clear distinction should > be made between the two, I feel this would clarify things a lot, especially > when you configure Postgres in a way which some scripts aren't comfortable > with (documentation or usagewise)- access control for instance. Not sure. > > Should there be mention of turning off fsync for performance reasons? Or is > that a bit risky/not officially supported? I find there is a dramatic > performance difference, however I'm still a bit nervous about it :). Also will be gone in 7.1. Was removed from book. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
At 06:28 PM 07-06-2000 -0400, Bruce Momjian wrote: >I have been told by the publisher that most changes to the book must be >done by next week. > >The book is at: > > http://www.postgresql.org/docs/awbook.html > >Again, many thanks to those that have supplied suggestions for the book. More "typical usage" examples on commands would be helpful. For example the cluster command may need a typical usage example. Not everyone can parse man pages and understand the differences with stuff being between <> and [] and {} so on... Typical usage examples can help the majority actually get things done. Also a LIMITS section/appendix would be very useful. This should list stuff like limits on tuples, queries, names, fields, data types, number of tables (theoretical and practical), number of indexes, and so on. It can be rather misleading to say that "text" has no limit and only when people bump into the tuple limit, we tell them of the infamous 8KB row/tuple limit. Naturally this would be out of date soon, but that just sets the stage for the 2nd edition ;). An example for "create user with password" would be good too - since the web example was unclear/problematic the last time I checked - I had to do some trial an error. Also another thing should be made clear: Stuff like vacuumdb, createdb etc are basically scripts, whereas the actual commands are vacuum, create database and so on. A clear distinction should be made between the two, I feel this would clarify things a lot, especially when you configure Postgres in a way which some scripts aren't comfortable with (documentation or usagewise)- access control for instance. Should there be mention of turning off fsync for performance reasons? Or is that a bit risky/not officially supported? I find there is a dramatic performance difference, however I'm still a bit nervous about it :). Cheerio! Link.
I'm hoping to use the pg_description table (in 7.0.2) to make a few databases more decipherable to local developers. Unfortunately, the only way I can see to put data in is by directly updating the pg_description table. Is there any documenation for possible alternative procedures? I was unfortunately unable to find any. What I would like would be something like: ALTER TABLE foo (ADD|UPDATE) DESCRIPTION 'Some Text Here'; and of course the ability set change psql setting to display descriptions for tables when I do '\dt' Does anything like this exist? Is it planned? -- Karl DeBisschop kdebisschop@alert.infoplease.com Family Education Network/Information Please http://www.infoplease.com Netsaint Plugin Developer kdebisschop@users.sourceforge.net
Karl DeBisschop wrote: > > I'm hoping to use the pg_description table (in 7.0.2) to make a few > databases > more decipherable to local developers. > > Unfortunately, the only way I can see to put data in is by directly > updating > the pg_description table. Is there any documenation for possible > alternative > procedures? I was unfortunately unable to find any. > > What I would like would be something like: > > ALTER TABLE foo (ADD|UPDATE) DESCRIPTION 'Some Text Here'; > > and of course the ability set change psql setting to display > descriptions for > tables when I do '\dt' > > Does anything like this exist? Is it planned? To add descriptions: COMMENT ON TABLE foo IS 'Some Text Here'; To drop the descriptions: COMMENT ON TABLE foo IS NULL; \h COMMENT should give yo all the details. Naturally, the comments are dropped when the associated object is dropped. You can comment on any PostgreSQL object and the comments are dumped with pg_dump. Hope that helps, Mike Mascari
Forgive any blatant ignorance, but maybe someone can help here. I've installed PostgreSQL 7.0 using the rpm on a Redhat 6.2 setup and was hoping to do a quick install of the Perl DBD::Pg module using perl -MCPAN -eshell. This failed and I got the message "please set the environment variables POSTGRES_INCLUDE and POSTGRES_LIB!". I'm not sure what to set these to, or even if this approach will work given that I intalled via rpm rather than having the source. Any thoughts? Thanks, Sean.
At 15:17 4/07/00 +1000, Sean Carmody wrote:
>perl -MCPAN -eshell. This failed and I got the message "please set
>the environment variables POSTGRES_INCLUDE and POSTGRES_LIB!". I'm
>not sure what to set these to, or even if this approach will work
>given that I intalled via rpm rather than having the source. Any
>thoughts?
They need to be set to
/usr/local/pgsql/include
and
/usr/local/pgsql/lib
on most systems; basically, they point to where the PG include & lib files
are.
(if you run SuSE, they may be under /var/lib/pgsql).
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Sean Carmody wrote: > > Forgive any blatant ignorance, but maybe someone can help here. > > I've installed PostgreSQL 7.0 using the rpm on a Redhat 6.2 setup > and was hoping to do a quick install of the Perl DBD::Pg module using > perl -MCPAN -eshell. This failed and I got the message "please set > the environment variables POSTGRES_INCLUDE and POSTGRES_LIB!". I'm > not sure what to set these to, or even if this approach will work > given that I intalled via rpm rather than having the source. Any > thoughts? For the RPM distribution, set POSTGRES_INCLUDE to /usr/include/pgsql, and POSTGRES_LIB to /usr/lib/pgsql -- although, depending upon what DBD::Pg needs about LIBs, you may want to set POSTGRES_LIB to /usr/lib. Or you can install the DBD::Pg RPM's -- see www.rpmfind.net to locate. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11