Re: code question: rewriteDefine.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: code question: rewriteDefine.c
Date
Msg-id 10249.1069401501@sss.pgh.pa.us
Whole thread Raw
In response to code question: rewriteDefine.c  (Neil Conway <neilc@samurai.com>)
Responses Re: code question: rewriteDefine.c
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Under what circumstances do we "convert a relation to a view"? Is this
> functionality exposed to the user?

This is a backwards-compatibility hangover.  pg_dump scripts from
somewhere back in the Dark Ages (6.something) would represent a view
asCREATE TABLE v (column-list);CREATE RULE "_RETURN" AS ON SELECT TO v DO INSTEAD ...;
and the code you are looking at is intended to convert this locution
into a genuine-per-current-representation view.

I'm not sure how important it is to continue supporting that.  But I'd
not want to break it just because someone thinks the hack is ugly.
It was ugly from day one.

> Furthermore, it seems broken: it checks the pgclass.relhassubclass
> attribute for this relation to see "if it has child tables", but this
> is wrong, as relhassubclass only indicates that the relation MAY have
> a subclass, not that is definitely does[1]. It also doesn't drop the
> relation's TOAST table, if any, as the code itself notes.

There could not be any child tables, either current or former, in the
intended application.  There could be a TOAST table, but getting rid of
it would only save some useless entries in pg_class etc, not prevent any
functional problems, so no one bothered.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4 logging bug.
Next
From: Teodor Sigaev
Date:
Subject: Re: tsearch2 patch for 7.4.1