Re: Possible patch for better index name choosing - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Possible patch for better index name choosing
Date
Msg-id 603c8f070912202011n45349c2dybca8b040d44ed4f@mail.gmail.com
Whole thread Raw
In response to Possible patch for better index name choosing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Possible patch for better index name choosing  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patch: Remove all declarations from pg_attribute.h, consolidate BKI scripts
Next
From: Bruce Momjian
Date:
Subject: Re: Removing pg_migrator limitations