> -----Original Message-----
> From: Bruce Momjian
>
> Christopher Kings-Lynne wrote:
> > > Uh, then what? The only idea I had was to set a static boolean
> > > variable in
> > > syscache.c that controls whether droppped columns are
> returned, and have
> > > a enable/disable functions that can turn it on/off. The only
> problem is
> > > that an elog inside a syscache lookup would leave that value set.
> > >
> > > My only other idea is to make a syscache that is like ATTNAME except
> > > that it doesn't return a dropped column. I could probably
> code that up
> > > if you wish.
> >
> > That'd be cool.
> >
> > I guess the thing is that either way, I will need to manually
> change every
> > single instance where a dropped column should be avoided. So, really
> > there's not much difference between me changing the SysCache
> search to use
> > ATTNAMEUNDROPPED or whatever, or just checking the attisdropped
> field of the
> > tuple in the same way that you must always check that attnum > 0.
> >
> > In fact, looking at it logically...if all the commands currently are
> > required to check that they're not modifiying a system column,
> then why not
> > add the requirement that they must also not modify dropped
> columns? I can
> > do a careful doc search and try to make sure I've touched everything...
>
> Makes sense. Of course, we could make a syscache that didn't return
> system columns either.
>
> Actually, the original argument for negative attno's for dropped columns
> was exactly for this case, that the system column check would catch
> dropped columns too,
> but it causes other problems that are harder to fix
> so we _dropped_ the idea.
What does this mean ?
BTW would we do nothing for clients after all ?
regards,
Hiroshi Inoue