Re: Outstanding patches

> I presume that Ian is not thinking about such a scenario, but only about
> using %type in a schema file that he will reload into a freshly created
> database each time he edits it. That avoids the issue of whether %type
> declarations can or should track changes on the fly, but I think he's
> still going to run into problems with function naming: do
> fooey(foo.bar%type) and fooey(foo.baz%type) conflict, or not? Maybe
> today the schema works and tomorrow you get an error.
>
> Basically I think that this feature does not coexist well with function
> overloading, and that it's likely to create as much or more grief as it
> avoids.

But don't we already have problems with changing functions that use
tables or does this open a new type of problem? Seems if you define a
function to be based on a column, and the column changes, the person
should expect errors.

If we define things as %TYPE in plpgsql, do we handle cases when the
column type changes?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026