Re: Plan invalidation design - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Plan invalidation design
Date
Msg-id 13028.1171829101@sss.pgh.pa.us
Whole thread Raw
In response to Re: Plan invalidation design  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Plan invalidation design  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> If you prepare "select *" and add a column, you're saying the query should
> start failing?

Either fail or change output; which you like better?  The whole point of
this exercise is to support plpgsql functions that do something like
create temp table foo ...select * into rec from foo ...drop table foo ...

and from the system's point of view successive executions of this
sequence are talking about completely different tables.  There's no
reason to suppose they have the same expansion of "*".  I'd also like
to think that the semantics of a plpgsql function are not going to
be different the first time it's executed in a session than subsequent
times, which suggests that indeed it ought to cope with "*" expanding
differently from last time.

To do what you're suggesting, we'd have to redesign parse analysis
so that expansion of "*" was a completely separate step from everything
else, producing a parse tree that's still raw except for that one change;
and I'm not sure what other strange decisions we'd have to make.  I
don't find that an attractive idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: RFC: Temporal Extensions for PostgreSQL
Next
From: Enrico
Date:
Subject: Re: return varchar from C function