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