Thus spake Tom Lane
> indkey and indclass are type int28 and oid8 respectively, which are
> almost like 8-element arrays, except that for historical reasons they
> index from 0 not 1. So instead of pg_index.indkey[0] = pg_attribute.attnum
> write pg_index.indkey[1] = pg_attribute.attnum to find attributes that
> are secondary index columns, [2] for tertiary, etc. Unused positions
> in indkey[] are filled with zeroes.
I understand all that. I was just looking for a SQL statement to pull
them all out. If we can't manipulate arrays in SQL I'm not sure that
they really belong here, especially in system tables. Perhaps indkey
should be pulled out to another table instead.
> If you have code on the client side it'd probably make most sense just
> to pull back the whole value of indkey[] and then issue separate SELECTs
> to find out what the referenced attributes are, instead of probing 8
> times to see if you get anything...
Seems real klugy. The system should be able to handle it in the backend.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
