Bruce Momjian <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
