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