Skip site navigation (1) Skip section navigation (2)

Re: SQL scripts - sequences

From: Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>
To: aalang(at)rutgersinsurance(dot)com
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: SQL scripts - sequences
Date: 2000-08-29 18:51:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
   Is it safe and accurate?  Should I be able to feel mostly secure about using
   that to dump my database definitions?

As safe and accurate as it gets without having a set of scripts that
loaded the data in the first place (barring you writing something
better, of course).

The main catch is that all the metadata about relations doesn't seem
to be preserved within the database and so can't be dumped with
pg_dump (correct me if I'm wrong).  Consequently, I have relied on
keeping scripts for the setup of relations and using pg_dump for the

   In the script below, I get this error after each references statement: 
   NOTICE:  CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented

You're using an old release.  Upgrade.

   Nope, I'm running 6.5.  Besides upgrading to 7 (I tried once and it was a
   pain in the ass.  I'm running RedHat6.2 and I only had about a million
   dependencies to update also... one which I never got working...), what can I
   do? Technically I really don't need the references, just a nice addition.

You really do want references for maintaining data integrity.  Can't
you upgrade PostgreSQL without upgrading the OS?  If you use pg_dump
it shouldn't be that bad.  (Or use the NetBSD pkgsrc system which
pretty much automates the installation except for loading the
relations/data. :) There are even some hooks for using the pkgsrc
system with Linux, I think.


In response to


pgsql-general by date

Next:From: Lamar OwenDate: 2000-08-29 18:57:00
Subject: Re: PG 7.0.2 Install
Previous:From: Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=Date: 2000-08-29 18:48:22
Subject: Re: PG 7.0.2 Install

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group