Re: Outstanding patches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Outstanding patches
Date
Msg-id 8733.989359687@sss.pgh.pa.us
Whole thread Raw
In response to Re: Outstanding patches  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Re: Outstanding patches  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Outstanding patches
Next
From: Richard Poole
Date:
Subject: Re: Re: Outstanding patches