From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Outstanding patches |
Date: | 2001-05-08 22:08:07 |
Message-ID: | 8733.989359687@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> But don't we already have problems with changing functions that use
> tables or does this open a new type of problem?
But this feature isn't about functions that use tables internally;
it's about tying the fundamental signature of the function to a table.
I doubt that that's a good idea. It definitely does introduce potential
for problems that weren't there before, per the illustrations I already
gave.
You commented earlier that it's easy to "change the width of a column"
with this approach, but that's irrelevant, because atttypmod is not part
of a function's signature anyhow.
> If we define things as %TYPE in plpgsql, do we handle cases when the
> column type changes?
Sort of, because we just need to drop the cached precompiled version of
the function --- you can do that by starting a fresh backend if nothing
else, and we have speculated about making it happen automatically.
Changing a function's signature automatically is a MUCH bigger and
nastier can of worms, because it affects things outside the function.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Poole | 2001-05-08 22:15:53 | Re: Re: Outstanding patches |
Previous Message | Bruce Momjian | 2001-05-08 21:55:54 | Re: Outstanding patches |
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Poole | 2001-05-08 22:15:53 | Re: Re: Outstanding patches |
Previous Message | Jeff Duffy | 2001-05-08 22:05:16 | Re: Why?? executeQuery() & exception: "No results were returnedby the query." |