Re: Outstanding patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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