Re: Possible patch for better index name choosing
От | Robert Haas |
---|---|
Тема | Re: Possible patch for better index name choosing |
Дата | |
Msg-id | 603c8f070912202011n45349c2dybca8b040d44ed4f@mail.gmail.com обсуждение исходный текст |
Ответ на | Possible patch for better index name choosing (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Possible patch for better index name choosing
|
Список | pgsql-hackers |
On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Attached is a WIP patch for addressing the problems mentioned in this > thread: > http://archives.postgresql.org/pgsql-hackers/2009-12/msg01764.php > > The main things that it does are (1) consider all index columns, not > just the first one as formerly; and (2) try to generate a usable name > for index expression columns, rather than just ignoring them which was > the effective behavior formerly. I'm not really sure there's any point to this. Anyone who cares about giving their index an intelligible name should manually assign one. If they don't bother doing that, I don't really see why we should worry about it either. If anything, it seems like we should err on the side of simplicity, since some users (or even applications) might attempt to identify or predict automatically generated names. > A different consideration is whether it's really a good idea to be > messing with default index names at all. As illustrated in the attached > regression diffs, this does impact the error messages returned to > applications for unique-index failures. I don't think this is a serious > problem across a major version update, but maybe someone thinks > differently. Maybe I'll reserve final judgement pending further discussion, but my first reaction is to say it's not worth the risk. Probably this shouldn't be an issue for a well-designed application, but the world is full of badly-written code. We shouldn't throw up barriers (even relatively trivial ones) to updating applications unless we get something out of it, and I'm not convinced that's the case here. ...Robert
В списке pgsql-hackers по дате отправления: