Re: DROP COLUMN Progress
От | Christopher Kings-Lynne |
---|---|
Тема | Re: DROP COLUMN Progress |
Дата | |
Msg-id | GNELIHDDFBOCMGBFGEFOGEAJCDAA.chriskl@familyhealth.com.au обсуждение исходный текст |
Ответ на | DROP COLUMN Progress ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | pgsql-hackers |
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > >> That was my first thought also, but then the wrong attnum would be used > >> in the "make_var". Ugh. I think what Chris needs to do is extend the > >> eref data structure so that there can be placeholders for dropped > >> attributes. Perhaps NULLs could be included in the list, and then the > >> code would become like > > > Hmmm... I don't get it - at the moment I'm preventing them from even > > getting into the eref and all regression tests pass and every test I try > > works as well... > > Are you checking access to columns that're to the right of the one > dropped? OK, interesting: test=# create table test (a int4, b int4, c int4, d int4); CREATE TABLE test=# insert into test values (1,2,3,4); INSERT 16588 1 test=# alter table test drop b; ALTER TABLE test=# select * from test;a | d | d ---+---+---1 | 3 | 4 (1 row) It half works, half doesn't. Sigh - how come these things always turn out harder than I think!? pg_attribute: test=# select attrelid,attname,attisdropped from pg_attribute where attrelid=16586 and attnum > 0;attrelid | attname | attisdropped ----------+-----------+-------------- 16586 | a | f 16586 | dropped_2 | t 16586 | c | f 16586 | d | f (4 rows) Chris
В списке pgsql-hackers по дате отправления: