Itagaki Takahiro <itagaki.takah...@oss.ntt.co.jp> writes: > Thank you for reviewing. An updated patch is attached.
I applied this with some revisions. I didn't like the fact that error reports for functional indexes came out with "pg_expression_n" instead of something useful. I tweaked things to use the pg_get_indexdef code to obtain proper descriptions of the columns. (This also resulted in deciding to make the separator ", " instead of just ",", because that's what pg_get_indexdef does.) The API for the reporting function wasn't going to work at all for non-btree indexes, because they don't necessarily have index tuples that contain exactly the values to be reported. (In particular, hash doesn't.) I refactored things a bit to pass Datum/isnull arrays instead of an IndexTuple. This also led to moving the reporting function to genam.c, because it no longer had anything to do with IndexTuples. We're still not there for being able to support unique hash indexes with this, because it's still supposing that the index's tupledescriptor tells the input column datatypes. However that's an internal matter now for the reporting function, instead of being baked into its API. (I actually don't see a very easy way to get the column datatypes --- we'll need to think about that some, when and if unique hash indexes ever happen.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers