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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ERROR: cannot convert relation containing dropped columns to view
Дата
Msg-id 32123.1456789191@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ERROR: cannot convert relation containing dropped columns to view  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
I wrote:
> Nicklas =?ISO-8859-1?Q?Av=E9n?= <nicklas.aven@jordogskog.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


В списке pgsql-general по дате отправления:

Предыдущее
От: Geoff Winkless
Дата:
Сообщение: Re: multicolumn index and setting effective_cache_size using human-readable-numbers
Следующее
От:
Дата:
Сообщение: Looking for pure C function APIs for server extension: language handler and SPI