> On Aug 25, 2015, at 1:38 PM, Karsten Hilbert <karsten.hilb...@gmx.net> 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. Neil -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
