Re: [HACKERS] Re: [SQL] Column name's length
От | Zalman Stern |
---|---|
Тема | Re: [HACKERS] Re: [SQL] Column name's length |
Дата | |
Msg-id | 199906012335.QAA28839@netcom15.netcom.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [SQL] Column name's length (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: [SQL] Column name's length
|
Список | pgsql-hackers |
> How about something like this: if the code finds that the names are > too long when forming an implicit index name, it truncates the names > to fit, and you are OK as long as the truncated name is unique. > For example > > create table averylongtablename (averylongfieldname serial); > > would truncate the input names to produce something like > > averylongtable_averylongfie_key > averylongtable_averylongfie_seq > > and you'd only get a failure if those indexes/sequences already existed. > (Truncating both names as shown above, not just the field name, > should reduce the probability of collisions.) This only partially solves the problem and can introduce bugs into code which is only reading from a database. When someone is setting up the database to work on the system, they'll in theory get a failure so they know it won't work. This really isn't true for our software though because we have functions which dynamically query a table to see what columns it has. In theory two queries for different longnames can resolve to the same column name. It is also a backwards compatibility hassle if you ever want to increase the number of significant characters in the name. This is because the existing database only knows the first 32 characters and *must* ignore anything after that in lookups. You would have to keep track of which names are "old style" and which are new. Why set yourself up like that? -Z-
В списке pgsql-hackers по дате отправления: