> 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.
Yea, that is more an Informix issue.
> > 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.
OK, one idea is to throw a elog(NOTICE) when they use this feature,
stating that it will not track column changes. Another option is to
just forget about the feature entirely. Do we have people who like this
feature? Speak up now. If not, we will drop it.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
