Actually, I'm pretty sure this is on the TODO. It can't really happen until we have the ability to somehow divorce on-disk ordering from what's presented in the catalog. It's not exactly rocket science to make this happen, but it is quite a bit of work... On Fri, Jan 06, 2006 at 10:59:12AM -0600, John McCawley wrote: > I believe that it makes a lot of practical difference, just like > organizing related code into files, classes etc. is important for > clarity. This isn't a trivial thing, and the other (sarcastic?) > suggestion that I reorder my select misses the point. > > I think that having a good visual representation of the database is > extremely important. So much so that I wrote my own tool to do it > because one didn't exist for Postgres at the time. But I also think > it's important for this visual representation to be tied to the database > such that changes to the DB reflect in the visual representation and > vice versa. That's why I was asking my question about column order. It > would be bad to allow a user to move a column in the visual > representation when it is unable to be modified in the database. > > I'm sure that it's a difficult feature to implement at the database > level, and I'm sure there are sound technical reasons why it hasn't been > implemented, but I do believe that it is a desirable feature. > > > Berend Tober wrote: > > >John McCawley wrote: > > > >>Is there a way to change the order of columns in a table in Postgres > >>after it has been created? ... > > > > > >The best way to do it is when you have the opportunity to do a > >restore, edit the pg_dump output between the dump and the restore > >steps. There are other approaches that might not be feasible depending > >on circumstances, like dropping and recreating the table and reloading > >data, but you have to deal with foreign key and other dependencies and > >so it is probably more work than justifiable for something that makes > >no practical difference. > > > >Regards, > >Berend Tober > > > > > > > >---------------------------(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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > message can get through to the mailing list cleanly > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
