Wednesday, October 05. 2011Sweat the small stuff, it really mattersPrinter FriendlyTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I have never seen a use for "CREATE TABLE .. IF NOT EXISTS." that did not involve poor schema change management at minimum, allowing configuration problems to be made worse by leaving tables where they should not be, and often accompanied by giving too many privileges to the web application. I guess if we have to let MySQL users abandon their sloppy database, we have to let them keep some of their sloppy DBA practices.
I think that in PostgreSQL, a table's column order represents the order of the columns on disk. A while ago, it was discussed that PostgreSQL could add a specified order for table_name.* expansion, so that column order changes does not require changes to the disk layout.
Matt,
All I can say is you have lived a very sheltered life and it would do you good to "eat more dirt" as my mother would say - dirt is good for children - builds your immune system :) A classic example in PostGIS 2.0 we are still in development -- we want people ideally to have an easy upgrade regardless of when they built PostGIS 2.0 right because they ahve a lot of data they are playing with that they ideally don't want to reload. Our structures are in flux. We may add a table -- we want to create the table only if they don't have it.
Regarding replacing a view I completely agree with you!
Regarding the re-ording of the columns: I have never understood why people want to do that (and I never missed this in Oracle or Postgres). The desired column order can always be specified within the SELECT list
In general, I have found that using schemas allows most of the benefits without the pitfalls (no REPLACE someone else's function or relation ).
Put a DROP SCHEMA my_schema IF EXISTS CASCADE; CREATE SCHEMA my_schema; At the top of your script and it's less typing too. Of course you have to maintain separate schemas for the application logic and the user data, but that's probably a good idea anyway.
Tom,
Yah and if I happen to have data in other schemas that depends on data or functions in the schema you just kindly DROP CASCADED GOOD BYE data. Data is over-rated anyway :).
For those interested, I created a page on the postgres wiki (http://wiki.postgresql.org/wiki/Alter_column_position) which reviews the "alter column position" problem, including work arounds, and one possible implementation of the feature into postgres core. It's been 5 years since that plan was developed, so I wouldn't expect it to happen, but the idea is there. (Someone once showed up claiming to have implemented the pieces for physical re-ordering, but they never showed the code, so the claim is probably questionable).
|
Entry's LinksQuicksearchCalendar
Categories
Blog Administration |