From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org, harding(dot)ian(at)gmail(dot)com |
Cc: | Scott Ribe <scott_ribe(at)killerbytes(dot)com> |
Subject: | Re: Reordering columns in a table |
Date: | 2006-01-07 19:45:44 |
Message-ID: | 200601071445.44753.xzilla@users.sourceforge.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general |
You should be able to do this now using pg_depend, it would just take a bit of
leg-work. Pretty sure it would be easier than solving physical/logical
attribute separation. Someone writing a pg_list_all_dependencies function
would make for a really good head start... I wonder if the newsysviews
provides anything like that.
Robert Treat
On Friday 06 January 2006 22:34, Ian Harding wrote:
> As I recall, the MS SQL Server draggy droppy diagrammer tool made it
> seem trivial to rearrange columns did the same thing. It just
> generated SQL statements to:
>
> Begin transaction
> select data in new order into a new table
> drop dependent objects
> drop old table
> rename new table
> re-create dependent objects
> end transaction
>
> It seemed kinda squirrelly to me, but it worked most of the time since
> MSSQL Server had a good dependency tracking thingie. However, I would
> not really call it a feature of the DBMS. I would call it a bolted on
> utility.
>
> On 1/6/06, Scott Ribe <scott_ribe(at)killerbytes(dot)com> wrote:
> > > I would assume
> > > that all dependent database objects are also dropped when you drop the
> > > table, so you'd have to recreate all of your foreign keys (both
> > > directions) and triggers etc.?
> >
> > Basically. I try to keep my DDL scripts organized in a way that makes
> > this easy. Of course an automated tool could do this as well. For
> > instance I used to use the products from Embarcadero to maintain Sybase
> > databases, and their design tool would create all the DDL needed to
> > update a live database to match the current design. Of course, one
> > experience with a bug and I learned to have it show me the script and
> > read it carefully before proceeding ;-) (Hey, I'm not stupid, it was just
> > a development db that I hosed!)
> >
> >
> > --
> > Scott Ribe
> > scott_ribe(at)killerbytes(dot)com
> > http://www.killerbytes.com/
> > (303) 665-7007 voice
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2006-01-08 15:24:17 | Re: BUG #2155: problem with UNICODE and KOI8 |
Previous Message | Michael Meskes | 2006-01-07 19:11:36 | Re: BUG #2146: ECPG, cursros and conditional compilations... |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2006-01-07 20:00:46 | Re: 'Official' definition of ACID compliance? |
Previous Message | Christopher Browne | 2006-01-07 18:19:13 | Re: Oracle DB Worm Code Published |