[HACKERS] currentItemData currentMarkData
It has bothered me for some time that we have currentItemData and currentMarkData fields in IndexScanDescData, while it's really indexam's private data. They should be in the indexam opaque structure. At the moment, they're used in gist and hash access methods, and they're not used in b-tree and gin. The new bitmap index code uses them, but only as an internal boolean flag indicating that the scan has been initialized, so that should be fixed anyway. How about removing those fields from IndexScanDesc? There's also is_multiscan field which is set but never read. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] currentItemData currentMarkData
Heikki Linnakangas [EMAIL PROTECTED] writes: It has bothered me for some time that we have currentItemData and currentMarkData fields in IndexScanDescData, while it's really indexam's private data. They should be in the indexam opaque structure. Can't get very excited about it, but if you want. There's also is_multiscan field which is set but never read. It has been needed in the past and could plausibly be needed again sometime --- an index AM's rescan method might want to know what kind of scan it's setting up for. Of course, if we get rid of amgetmulti entirely as has been discussed, this'd go away too. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
