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
