> > > The thing is, physical index numbers has meaning, the logical index > > > number does not. In a view definition we're going to store the > > > physical index, not the logical one, for example. We don't want > > > rearranging columns to invalidate view definitions or plans. > > > > I think we lack a definition here: > > > > logical number: the order of columns when doing select * > > physical number: the position inside the heap tuple (maybe with > > offset) > > > > All views and plans and index definitions and most everyting else > > needs to reference the logical number. > > Huh? If I have an index on the first two columns of a table, > it's going > to refernce columns 1 and 2. > > If you alter the table to put a column in front of those two, the new > column will be physical 3, logical 1.
No, you change pg_index to now contain 2,3. > If the index references logical numbers, the index has just been > broken. If the index references physical numbers, everything works > without changes. yup, sinval > Same with views, if you use logical numbers you have to rebuild the > view each time. Why bother, when physical numbers work and don't have > that problem? Because it would imho be a nightmare to handle ... Andreas ---------------------------(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