Re: ANALYZE versus expression indexes with nondefault opckeytype

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> After a bit of study of the code, it appears to me that it's not too
> difficult to fix: we just have to use the expression's result type
> rather than the index column's atttypid in the subsequent processing.
> ANALYZE never actually looks at the index column contents (indeed
> cannot, since our index AMs provide no API for extracting the contents),

I don't think it'll be an issue, but just in case- is there any reason
this will cause trouble for the possible index-only quals/scans work?

> So that seems to make it not practical to back-patch.

But we could get it into 9.0..

> I thought of an ugly hack that would avoid an API/ABI break: since
> VacAttrStats.attr is a copy of the pg_attribute data, we could scribble
> on it, changing atttypid, attlen, attbyval, etc to match the index
> expression result type. This seems pretty grotty, but it would allow
> the fix to be back-patched into existing branches.

Yeah, that's rather nasty. :/

> Comments? I'm not sure which way to jump here.

For my 2c- let's get it fixed for 9.0 cleanly and encourage people who
run into this to upgrade to that once it's released. Perhaps I've
missed it, but I don't recall seeing many complaints about this.

Thanks,

Stephen