Re: [DOCS] Backup / restore procedure documentation
> Havard Eidnes <[EMAIL PROTECTED]> writes: > > However, I find that the documentation of the restore procedure as > > found in sections 9.1.1 and 9.1.2 in and of itself to be inadequate. > > Fair enough. I've tried to address this --- see CVS-tip docs at > http://developer.postgresql.org/docs/postgres/backup.html Thanks, this adresses my concern exactly. Best regaqrds, - Håvard ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Mysql -> Postgresql pitfalls
Excellent! That is exactly what I'm talking about. BTW, the "my2pg.pl" link is a dead link. Chad ---(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: [DOCS] Mysql -> Postgresql pitfalls
On Fri, 1 Aug 2003, Chad N. Tindel wrote: > Excellent! That is exactly what I'm talking about. > > BTW, the "my2pg.pl" link is a dead link. This is probably something that could be codified a bit here in the news group. I'd say the pitfalls I'm aware of are: autoincrement fields -> sequences full text indexing -> fts/tsearch etc... enum -> check constraint vacuum / analyze simple performance tuning (out of the box the postgresql.conf settings aren't really all that great, but they let postgresql come up on almost anything.) pg_hba.conf default setting that doesn't allow tcp/ip connections not being able to run postgresql as root (a good thing TM) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [DOCS] Mysql -> Postgresql pitfalls
> > Excellent! That is exactly what I'm talking about. > > > > BTW, the "my2pg.pl" link is a dead link. > > This is probably something that could be codified a bit here in the news > group. > > I'd say the pitfalls I'm aware of are: > > autoincrement fields -> sequences Yes. The documentation very clearly states using sequences instead of auto-increment, but it doesn't make it clear that inserting the id's into data by hand doesn't cause the sequence to be auto-matically incremented. It'd be nice of postgres had a way to trigger an update of the sequence value after every insert containing an id clumn. > not being able to run postgresql as root (a good thing TM) As a programmer, I personally would never write code that kept people from running things as root. I mean, what is the point? If an administrator wants to run postgresql or apache as root, why shouldn't they be allowed to make that conscious decision for themselves? As it is, you have to recompile apache with some BIG_SECURITY_HOLE defined in order to run as root, which means you can't just use the out of the box apache rpm. Its so stupid to write *extra* code that keeps people from doing something that isn't even fundamentally incorrect. All that being said, I don't think it causes too big of a problem for postgres installations. Chad ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] Mysql -> Postgresql pitfalls
"Chad N. Tindel" <[EMAIL PROTECTED]> writes: > As a programmer, I personally would never write code that kept > people from running things as root. I mean, what is the point? If someone roots your box, it's not our fault. Simple as that. Personally, I wish more net-accessible servers were written with that philosophy. The correct question is NEVER "why can't I run this as root?". The correct question is ALWAYS "how can I avoid running this as root? And if I can't avoid it, why not?". Any other approach leads to Outlook Express. (BTW, have you forgotten the SQL Server worm already?) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [DOCS] Mysql -> Postgresql pitfalls
On Fri, Aug 01, 2003 at 04:51:11PM -0400, Chad N. Tindel wrote: > > As a programmer, I personally would never write code that kept people from > running things as root. I mean, what is the point? If an administrator Hmmm? The point is something called security. > wants to run postgresql or apache as root, why shouldn't they be allowed > to make that conscious decision for themselves? As it is, you have to recompile Because administrators have too much to worry about. If an application makes a conscious decision to allow itself to run in a knowingly insecure manner, that application is doing the admin a disfavor, and should be ditched. > apache with some BIG_SECURITY_HOLE defined in order to run as root, which means > you can't just use the out of the box apache rpm. Its so stupid to write > *extra* code that keeps people from doing something that isn't even > fundamentally incorrect. This has no logic. Security is fundamental. No security is fundamentally incorrect. -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + ---/ NO INSPIRATION TODAY /--- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
