> 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@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
