On Wed, Oct 8, 2014 at 1:25 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > Instead of naming the index, you should name the columns, and the system can > look up the index or indexes that match those columns.
It's not totally clear that we need *any* WITHIN clause, BTW. I'm not dead set on it. It was something I mainly added at Kevin's request. I do see the risks, though. > (Remind me again, where did this need to name an index come from in the > first place?) I agree that naming indexes is ugly, and best avoided. It's tricky, though. The first thing you might try is to look up the index during parse analysis and/or planning. That could work in simple cases (which are probably the vast majority), but I'm worried about stuff like before row triggers that change the values being inserted out from under us, in a way that interferes with partial unique indexes. Maybe you could choose the wrong one if you didn't leave it until the last minute. But it's not very convenient to leave it until the last minute. If you're willing to live with the command conservatively failing when there isn't a clean specification (although not in a way that can make the command fail when the user innocently adds a unique index later), then I think I can do it. Otherwise, it could be surprisingly hard to cover all the cases non-surprisingly. I freely admit that putting a unique index in a DML statement is weird, but it is sort of the most direct way of expressing what we want. Oracle actually have an INSERT-IGNORE like hint that names a unique index (yes, really - see the UPSERT wiki page). That's really bizarre, but the point is that they may have felt that there was no reasonable alternative. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
