> > > The thing is, physical index numbers has meaning, the logical
> > > 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 ...


---------------------------(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

Reply via email to