Re: VIEW problem

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 #