Re: psql question - Mailing list pgsql-sql

From Josh Berkus
Subject Re: psql question
Date
Msg-id web-820536@davinci.ethosmedia.com
Whole thread Raw
In response to psql question  ("Joe Conway" <joe@conway-family.com>)
Responses Re: psql question  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-sql
CHarles,

> When I created TABLE clone I initially defined a column:
> 
> gb_accessions_id INTEGER REFERENCES gb_accessions(gb_accessions_id)
>  NULL
> 
> I have renamed TABLE gb_accessions to TABLE gb, and its column
>  gb_accessions_id to gb_id.
> 
> I next renamed the column 'gb_accessions_id' in TABLE clone to
>  'gb_id'.
> In renaming this column in TABLE clone I appear to have lost the
>  reference to TABLE gb (see below).
> 
> Questions:
> 
> 1. During which step in my renaming did this occur?
> 2. How should I have carried this out?
> 3. Can I add back REFERENCES gb(gb_id)?

I generally find that it is much easier, over all, to dump the databaseto a pgdump sql-text file, and do my editing
therewhenever I need tomake significant exits to important database tables.  Otherwise, it isdifficult to make sure
thatall of your constraints, rules, triggers,and FKs update correctly.
 

You can add back the REFERENCES constraints.  First, check the tabledefinitions of the child tables to see if they
stillhave orphanedconstraints pointing to gb_accessions.  (do this through psql's \dtable_name)  If so, drop those
constraints.

Unfortunately, I do not know the syntax for ALTER CONSTRAINT ...FORIEGN KEY ....   Post it as a question to the list.

-Josh


pgsql-sql by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: 7.0.3 pg_dump -> segmentation fault!
Next
From: "Andrew G. Hammond"
Date:
Subject: Re: How to grant a privilege on all tables or views or both of a database to someone?