Re: Plan invalidation design

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Russell Smith" <mr-russ(at)pws(dot)com(dot)au>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Plan invalidation design
Date: 2007-02-18 20:05:01
Message-ID: 13028.1171829101@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Enrico 2007-02-18 20:17:44 Re: return varchar from C function
Previous Message Jeremy Drake 2007-02-18 20:03:35 Re: patch adding new regexp functions