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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Patch: Remove all declarations from pg_attribute.h, consolidate BKI scripts
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Removing pg_migrator limitations