From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: code question: rewriteDefine.c |
Date: | 2003-11-21 07:58:21 |
Message-ID: | 10249.1069401501@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)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
as
CREATE 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
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2003-11-21 08:12:47 | Re: tsearch2 patch for 7.4.1 |
Previous Message | Tom Lane | 2003-11-21 07:49:28 | Re: 7.4 logging bug. |