Re: DROP COLUMN Progress

Christopher Kings-Lynne wrote:
> OK,
>
> This is the problem I'm having with the DROP COLUMN implementation. Since
> I've already incorporated all of Hiroshi's changes, I think this may have
> been an issue in his trial implementation as well.
>
> I have attached my current patch, which works fine and compiles properly.
>
> Ok, if you drop a column 'b', then all these work properly:
>
> select * from tab;
> select tab.* from tab;
> select b from tab;
> update tab set b = 3;
> select * from tab where b = 3;
> insert into tab (b) values (3);
>
> That's all good. However, the issue is that one of the things that happens
> when you drop a column is that the column is renamed to 'dropped_%attnum%'.
> So, say the 'b' column is renamed to 'dropped_2', then you can do this:
>
> select dropped_2 from tab;
> select tab.dropped_2 from tab;
> update tab set dropped_2 = 3;
> select * from tab where dropped_2 = 3;
>
> Where have I missed the COLUMN_IS_DROPPED checks???

OK, my guess is that it is checks in parser/. I would issue each of
these queries with a non-existant column name, find the error message in
the code, and add an isdropped check in those places.

> Another thing: I don't want to name dropped columns 'dropped_...' as I
> think that's unfair on our non-English speaking users. Should I just use
> 'xxxx' or something?

I think "dropped" is OK. The SQL is still English, e.g. DROP.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026