Re: [HACKERS] Re: [SQL] Column name's length
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: [SQL] Column name's length |
Дата | |
Msg-id | 23827.928273954@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [SQL] Column name's length (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: [SQL] Column name's length
Re: [HACKERS] Re: [SQL] Column name's length |
Список | pgsql-hackers |
We've seen this table-name-plus-column-name-too-long problem before, and I'm sure we're going to keep hearing about it until we fix it somehow. Messing with NAMEDATALEN is probably not a very useful answer for the average user, given the compatibility problems it creates. 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_keyaverylongtable_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.) You could even imagine trying a few different possibilities in order to find an unused name, but that worries me. I'd rather that it were completely predictable what name would be used for a given key, and if it depends on what already exists then it wouldn't be so predictable. But there's nothing unpredictable about truncation to fit a known length. This is obviously not a 100% solution, since there's a risk of name collisions (averylongfieldname1 and averylongfieldname2) but it's probably a 95% solution, and it wouldn't take much work or risk. Comments? Objections? I think I could argue that this is a bug fix and deserves to be slipped into 6.5 ;-) regards, tom lane
В списке pgsql-hackers по дате отправления: