I wrote: > Nicklas =?ISO-8859-1?Q?Av=E9n?= <nicklas.aven@xxxxxxxxxxxxx> writes: >> ERROR: cannot convert relation containing dropped columns to view > When we made rules with RETURNING go through this logic, in 2006, we > don't seem to have revisited the message text, much less thought about > whether we needed to take "more trouble" about dealing with dropped > columns in a real table. > I'm not sure how hard it would be to support the case. Given that yours > is the first complaint in ten years, and that rules in general are pretty > out of favor, it's probably not going to be very high on the to-do list. > My own inclination would just be to provide a more on-point error message > for this case. I spent half an hour or so trying to make this work, along the lines of what's suggested in the code comment (inserting dummy NULL entries into the tlist). While it's not terribly hard to make checkRuleResultList itself play along, it turns out that much of the rest of the backend is not prepared to deal with such entries. For example, although the RETURNING list seems to work okay as such: regression=# delete from foo where id = 2 returning *; id | deleted ----+---------------------------- 2 | 2016-02-29 18:30:04.116309 (1 row) you soon find that operations like rule decompiling think that the NULL entry means something: regression=# \d+ foo Table "public.foo" Column | Type | Modifiers | Storage | Stats target | Description ---------+-----------------------------+--------------------------------------------------+---------+--------------+------------- id | integer | not null default nextval('foo_id_seq'::regclass) | plain | | deleted | timestamp without time zone | | plain | | Rules: del_post AS ON DELETE TO foo DO INSTEAD UPDATE foo SET deleted = now() WHERE foo.id = old.id RETURNING foo.id, NULL::integer AS "........pg.dropped.2........", foo.deleted Trying to find everyplace that would have to be taught about that seems like a mess. It would definitely take a significant amount of work, and as I said earlier, I doubt anyone wants to invest the work. So I'm just going to go improve the comment and error message and leave it at that. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general