Re: ERROR: cannot convert relation containing dropped columns to view

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nicklas Avén <nicklas(dot)aven(at)jordogskog(dot)no>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: cannot convert relation containing dropped columns to view
Date: 2016-02-29 23:39:51
Message-ID: 32123.1456789191@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I wrote:
> Nicklas =?ISO-8859-1?Q?Av=E9n?= <nicklas(dot)aven(at)jordogskog(dot)no> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message david 2016-02-29 23:55:33 Looking for pure C function APIs for server extension: language handler and SPI
Previous Message Geoff Winkless 2016-02-29 23:02:25 Re: multicolumn index and setting effective_cache_size using human-readable-numbers