Re: column ordering, was Re: [PATCHES] Enums patch v2 - Mailing list pgsql-hackers

From Zeugswetter Andreas ADI SD
Subject Re: column ordering, was Re: [PATCHES] Enums patch v2
Date
Msg-id E1539E0ED7043848906A8FF995BDA57901A34ECD@m0143.s-mxs.net
Whole thread Raw
In response to Re: column ordering, was Re: [PATCHES] Enums patch v2  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
> > > 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2
Next
From: "Kevin Grittner"
Date:
Subject: Re: column ordering, was Re: [PATCHES] Enums patch