Teodor Sigaev <teo...@sigaev.ru> writes:
> I found problem while vacuuming with composite type (version 9.0.4). It's not
> so
> easy to reproduce, but it's clear what happens.
> CREATE TYPE mytype AS (p point, r float8);
> CREATE TABLE mytable (mt mytype);
> -- create opclass fir GiST
> CREATE INDEX myidx ON mytable USING gist (mt);
> And vacuum fails with message:
> ERROR: could not identify a comparison function for type point
It's worse than that, actually: you'll get the same failure from ANALYZE
even without the GIST index, as long as there's some data in the column.
And even if you try to make ANALYZE back off to use
compute_minimal_stats, it still fails, because there's no btree equality
for type point either.
We've also seen similar failures in respect to things like the planner
trying to use sorting with unsortable composite types. So this issue
isn't really specific to ANALYZE. I'm inclined to think that the most
reasonable fix is to make get_sort_group_operators() and related
functions recursively verify whether the component types can be compared
before they claim that record_eq, array_eq, etc can be used. So that
would require special cases for composites and arrays in those
functions, but at least we'd not need to hack up all their callers.
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
