Re: [GENERAL] Best Perl Option?
Quoting David Busby [EMAIL PROTECTED]: List, Which of the may Perl Modules on CPAN should I use for PostgreSQL. I'd prefer the fastest/most up to date module. Which is it or do I have to dig through them all? David Busby Systems Engineer [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html David, What are you looking to do? The basic stuff is the database connection which can be handled by Pg.pm or DBD:Pg (DBI stuff). Authorization modules for Apache are plentify on CPAN. I've never used any because I ended up writing my own but they have been discussed here as well. That's just the basics though. Don't forget you also have the option writing your SP's in pl/perl as well. That has nothing to do with modules but has everything to do with perl and being about to write your server side functions in a language that your are comforatable with :) Good luck! -- Keith C. Perry Director of Networks Applications VCSN, Inc. http://vcsn.com This email account is being host by: VCSN, Inc : http://vcsn.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] database speed
Quoting Doug McNaught [EMAIL PROTECTED]: Chris Stokes [EMAIL PROTECTED] writes: The REINDEX is needed because VACUUM doesn't free up index space in some circumstances. 7.4 (currently in late beta) will fix this. Sorry Doug, Yes I am doing a vacuum regularly - in fact, when the speed of the DB becomes slower, the vacuum takes longer and longer too. I have never used the REINDEX I wondered if it might be a row chaining issue of some sort ?!? The index bloat problem can occur when you have a an indexed SERIAL column whose value always increases, and you delete older rows on a regular basis. VACUUM recycles the row storage, but the index never shrinks. You can check: next time you get the speed/data growth problem, find which files in the database directory are growing, and use 'oid2name' (in the source tree under 'contrib') to find out what they are. Odds are they are indexes and REINDEXing their table will fix the problem. If you are running a recent version of PG (7.3 and maybe 7.2 as well) and have a very active database, you may also need to increase your free space map (FSM) size in postgresql.conf, and possibly run VACUUM FULL once a week or so. -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Speaking of recent versions... In 7.4, doesn't the cluster command address this problem? -- Keith C. Perry Director of Networks Applications VCSN, Inc. http://vcsn.com This email account is being host by: VCSN, Inc : http://vcsn.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] grant all to database inheritence
On Mon, Oct 27, 2003 at 16:58:50 -0500, Dave Cramer [EMAIL PROTECTED] wrote: I have a challenge to be able to grant all to the database, and then have subsequent tables accessible by all users. Granting access to a database does specifically what the documentation says it does, which does affect the default access rights for newly created objects. It seems to me that this is how a database should work. I do realize that postgres doesn't do this now. Is there a way around this? Using rules or some other mechanism? Currently there really isn't a way to do this. You could run a cron script that sets protections for tables on a regular schedule. What it seems you really want is a per user or per database value that specifies a default access mode for newly created objects roughly similar to umask on Unix systems. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] regular backups - super user
Hello, Your pg_hba.conf controls the authentication model for your machine. One way to handle this is to have the database on a local machine and allow anything local (not localhost/127.0.0.1) to be of type trust. You should only do this if you trust the people that have access to shell accounts on that machine. Then set your network connections to be of type md5 (better yet use hostssl as well). Sincerely, Joshua D. Drake Paul Thomas wrote: On 30/10/2003 15:29 Jeff MacDonald wrote: Hi, WHen i run pg_dumpall as the super user [postgres in my case] it asks for a password for every database. I don't know my users passwords. Is there a way to make the super user able to backup without passwords ? What version of PG are you using? I've just tried this on my 7.3.4 box and I don't get asked for user passwords. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [SQL] connectby
I use postgresql 7.2.3 How can I use connectby ?? Must I install files ? or packages ? or it is recommanded to upgrade dataserver ? For recent versions of PostgreSQL, go into the contrib/tablefunc directory and see the readme file for how to install. I downloaded PostgreSQL 7.2.3 and there was no contrib/tablefunc directory. You'll have to upgrade. George Essig ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html