On Tue, 25 Aug 2015 18:57:28 -0400, Neil Tiffin <ne...@neiltiffin.com>
wrote:
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
I suspect he's alluding to migration scripts from an ORM - which are
typically scaffolded with boilerplate, but almost invariably need to be
tweaked in order to effect the desired changes in the database..
- John
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
