Hm, I think that it would be quite clear to set it to zero for non-unique indexes. (nunique == 0) is equal to (indisunique==false).
But maybe I've missed some reason why we should to save indisunique flag.
I'd say that Jim summed this one up well, with:
>... we might want to support INCLUDE at some point. It enhances covering scans without bloating the heck out of the btree. (I'm not sure if it would help other index types...) So it seems like a bad idea to preclude that.
Which I take to mean non-unique indexes.
So if you just kept the indisunique flag, and added a column to state the number of columns that are actually in the "index" (not INCLUDE columns). Then your code would probably work for both unique and non-unique index. This way users don't have to pay the price of index bloat if they tag on high cardinality columns onto the end of the index's column list.
Perhaps it would be easier just to add a new column to pg_index which stores the total attrs, that way you could get away with not having to edit each of the existing for() loop that go over the index attributes. This would just store the idxnattrs + number of included columns. Perhaps something named idxtotnatts or idxtotalnatts.
