From 336c1d7a515b4d6de237679022d70082d7b69d9a Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 16 Oct 2011 19:15:04 -0400 Subject: Avoid assuming that index-only scan data matches the index's rowtype. In general the data returned by an index-only scan should have the datatypes originally computed by FormIndexDatum. If the index opclasses use "storage" datatypes different from their input datatypes, the scan tuple will not have the same rowtype attributed to the index; but we had a hard-wired assumption that that was true in nodeIndexonlyscan.c. We'd already hacked around the issue for the one case where the types are different in btree indexes (btree name_ops), but this would definitely come back to bite us if we ever implement index-only scans in GiST. To fix, require the index AM to explicitly provide the tupdesc for the tuple it is returning. btree can just pass back the index's tupdesc, but GiST will have to work harder when and if it supports index-only scans. I had previously proposed fixing this by allowing the index AM to fill the scan tuple slot directly; but on reflection that seemed like a module layering violation, since TupleTableSlots are creatures of the executor. At least in the btree case, it would also be less efficient, since the tuple deconstruction work would occur even for rows later found to be invisible to the scan's snapshot. --- doc/src/sgml/indexam.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/src') diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml index 80f55da87b3..a6e4466e8a1 100644 --- a/doc/src/sgml/indexam.sgml +++ b/doc/src/sgml/indexam.sgml @@ -396,7 +396,8 @@ amgettuple (IndexScanDesc scan, row), then on success it must also check scan->xs_want_itup, and if that is true it must return the original indexed data for the index entry, in the form of an - IndexTuple pointer stored at scan->xs_itup. + IndexTuple pointer stored at scan->xs_itup, + with tuple descriptor scan->xs_itupdesc. (Management of the data referenced by the pointer is the access method's responsibility. The data must remain good at least until the next amgettuple, amrescan, or amendscan -- cgit v1.2.3