Re: Possible patch for better index name choosing

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible patch for better index name choosing
Date: 2009-12-21 04:11:25
Message-ID: 603c8f070912202011n45349c2dybca8b040d44ed4f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 20, 2009 at 10:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-12-21 04:58:01 Re: Removing pg_migrator limitations
Previous Message Robert Haas 2009-12-21 03:55:55 Re: Patch: Remove all declarations from pg_attribute.h, consolidate BKI scripts