> 1. Should not "break" out of loop over indexes after detecting a
> matching non-primary-key index. This allows detection of the NOTICE
> condition to distract you from detecting the ERROR condition on a
> later index. I'd suggest issuing the NOTICE inside the loop, actually,
> and not breaking at all. (See also #4)
I don't quite understand what you mean here?
> 2. What's with the "if (keyno > 0)"? That breaks detection of
> everything on indexes on system columns, eg OID. (Of course, the
> "rel_attrs[keyno - 1]" reference doesn't work for system columns,
> but sticking your head in the sand is no answer.)
That is that part of the code that I least understand, so I would
appreciate it if someone took 1 minute and told me how this _should_ be
written. Note that I used this code from the ADD FOREIGN KEY stuff.
/* Look at key[i] in the index and check that it is over the same column as key[i] in the constraint. This is to
differentiatebetween (a,b) and (b,a) */if (i < INDEX_MAX_KEYS && indexStruct->indkey[i] != 0){ int keyno =
indexStruct->indkey[i];
if (keyno > 0) { char *name = NameStr(rel_attrs[keyno - 1]->attname); if (strcmp(name, key->name) == 0)
keys_matched++; }}
I admit I was confused as to why it's keyno - 1??
> 3. pfree'ing iname at the bottom doesn't strike me as a good
> idea; isn't that possibly part of your input querytree?
OK, gone.
> 4. If you're going to be so pedantic as to issue a warning notice about
> a duplicate non-primary index, it'd be polite to give the name of that
> index. Else how shall I know which index you think I should drop?
I was going to do this, but then realised all I had access to in the
indexStruct was the oid of the index relation? What's the easiest way of
retrieving the name of an index given it's oid, or the oid of it's
relation?
Once I've figured these probs out, I'll fix the ADD UNIQUE code as well.
Chris