haskeytype and index_formtuple - Mailing list pgsql-hackers
From | Oleg Bartunov |
---|---|
Subject | haskeytype and index_formtuple |
Date | |
Msg-id | Pine.GSO.4.33.0105291629270.14271-100000@ra.sai.msu.su Whole thread Raw |
Responses |
Patch for multi-key GiST
|
List | pgsql-hackers |
Hi, to continue discussion about pg_index.haskeytype (see http://fts.postgresql.org/db/mw/msg.html?mid=117845 http://fts.postgresql.org/db/mw/msg.html?mid=119796 ) I'd like to remind that pg_index.haskeytype *was used* up to 7.1 version. It's indicate that type of key is different from that of column ! in 7.0.2 it was possible to use following syntax: create table TT (i int); create index TTx on TT using gist (i:intrange gist_intrange_ops); i:intrange indicates that type of key is intrange while column 'i' has type int. So, index_formtuple used length of key from intrange. pg_index.haskeytype was a flag which indicates to index_formtuple to use information about key from other type. In this example - use intrange instead of int. In 7.1 version pg_index.haskeytype is always true, i.e. type of key is always the same as type of column and syntax 'i:intrange' became unavailable. Notice, that for fixed length columns it's necessary that lengths of key and column must be the same. I don't think we need to restore pg_index.haskeytype and syntax because: 1. This is not suited for multi-key GiST - we need something like this for each subkey 2. Syntax is very ugly and useless - all information (type of key, losiness) should be stored somewhere in system tables. In such sense, we vote pg_index.haskeytype could be totally removed from current sources. Tom, would you like to implement storage for type of key suitable for multi-key ? It's very important for correct implementation of GiST we're working on. We have implemented multi-key GiST (posted) and R-Tree ops for GiST (full implementation, posted with workaround for poly_ops - key is variable length but length is constant and equal 36 bytes = sizeof(BOX)+key_length ). Currently we're implementing B-Tree opses but we have problems because while types of key and column are fixed but length of key is greater than that of column type. Again, we need index_formtuple which knows type of key ! Regards, Oleg 7.0.3 backend/catalog/index.c indexForm->indhaskeytype = 0; while (attributeList != NIL) { IndexKey = (IndexElem *) lfirst(attributeList); if (IndexKey->typename != NULL) { indexForm->indhaskeytype = 1; break; } attributeList= lnext(attributeList); } 7.1 indexForm->indhaskeytype = true; /* not actually used anymore */ 7.0.3 backend/parser/gram.y index_elem: attr_name opt_type opt_class { $$ = makeNode(IndexElem); $$->name = $1; $$->args= NIL; $$->class = $3; $$->typename= $2; } ; 7.1 index_elem: attr_name opt_class { $$ = makeNode(IndexElem); $$->name = $1; $$->args= NIL; $$->class = $2; } ; _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
pgsql-hackers by date: