Tim Uckun wrote:
> At 05:48 PM 10/5/2000 +1100, you wrote:
>
> >I believe this is because the OIDs are not identical. Internally, Postgres is
> >referring to the OIDs and not to the table name. Might be wrong, I am only a
> >postgres newbie, but I think this is the case.
>
> Interesting this makes sense.
>
> >I don't think it is a bug either, this is rather correct and prevents the
> >database from doing the wrong thing (your new table foo could be completely
> >different from the first table foo)
>
> Here I have to disagree with you. I can't believe that this behaviour was
> intended. A view is not materialized and it's simply a RULE which is to say
> that it's nothing more then a SQL statement. As long as that SQL statement
> is valid, parseable and returns a recordset it really ought not to care
> about oids.
You're right and this is a long standing - let's say lacking
capability instead of bug.
The problem is that the rules aren't stored as their queries
string representation, given in the original CREATE RULE
statement. Instead, the internal queries parsetree
representation is stored to avoid the need to parse the rules
any time they're used again. In the case of a DROP/CREATE of
an underlying object, this preparsed querytree becomes
invalid, so that the view would need to be recompiled, so to
say. But the system doesn't know the original definition any
more so it can't.
I have a personal TODO on this.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
