On Wed, Aug 26, 2015 at 09:04:08AM -0400, John Turner wrote: > >>>In most cases developers don’t care about index, unique, foreign key, > >>>or primary key names (from a coding standpoint) > >> > >>Until the day they’d like to write a reliable database change script. > > > >Not sure I understand. Once the object is created the name is set, it > >does not change, so I don’t understand why it is not possible to write a > >reliable database change script. Dump and restore maintain the name. Of > >course every project has periodic scripts that need to run, so these > >objects would, if they are dropped or manipulated in the script, have to > >be manually named, especially during development since the whole database > >might be dropped and recreated multiple times. My original comment > >included that situation. My projects typically have many, many objects > >that once created are not referred to again, unless a DBA is doing some > >tuning or troubleshooting. In that case, the DBA just looks up the name. > > > >I can see if say 2 years later you want to create a development database > >from the original SQL that generated the original table definitions that > >could be problematic. But I always have used the current definitions not > >the original and those can be exported with the current names. > > > >It just seems like busy work to me, but I would love to be enlightened. > > I suspect he's alluding to migration scripts from an ORM Not in the least. https://github.com/ncqgm/gnumed/tree/master/gnumed/gnumed/server/sql Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
