Re: Outstanding patches - Mailing list pgsql-hackers

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> We need to discuss whether we like the %TYPE feature proposed by Ian
>> Taylor.  It seems awfully nonstandard to me, and I'm not sure that the
>> value is great enough to be worth inventing a nonstandard feature.
>> ISTM that people don't normally tie functions to tables so tightly that
>> it's better to define a function in terms of "the type of column foo
>> of table bar" than just in terms of the type itself.  Ian claims that
>> this is helpful, but is it really likely that you can change that column
>> type without making *any* other mods to the function?  Moreover, in
>> exchange for this possible benefit you are opening yourself to breaking
>> the function if you choose to rename either the column or the table.
>> The potential net gain seems really small.  (If we do like the
>> functionality, then the patch itself seems OK with the exception of the
>> gram.y definition of func_type; the table name should be TokenId not
>> just IDENT.)

> I thought it was valuable.  I know in Informix 4gl you can set variables
> to track column types, and it helps, especially when you make a column
> longer or something. It also better documents the variable.

But it's not really tracking the variable; with Ian's proposed
implementation, after
    create table foo(bar int4);
    create function fooey(foo.bar%type) ...;
    drop table foo;
    create table foo(bar int8);

you would still have fooey declared as taking int4 not int8, because
the type meant by %type is resolved and frozen immediately upon being
seen.

Moreover, because of our function-name-overloading feature, fooey(int4)
and fooey(int8) are two different functions.  IMHO it would be a bad
thing if we *did* try to change the signature.  We'd break existing
callers of the function, not to mention possibly run into a naming
conflict with a pre-existing fooey(int8).

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.
        regards, tom lane