Jim Nasby <Jim.Nasby@BlueTreble.com> writes: > On 3/3/16 4:51 AM, Pavel Stehule wrote: >> CREATE TABLE a(a int); >> CREATE TABLE b(a a.a%TYPE) >> >> And the people expecting the living relation between table a and table >> b. So when I do ALTER a.a, then b.a should be changed. What if I drop >> a.a or drop a? >> >> So this is reason, why I don't would this feature in SQL side.
> I don't buy that. plpgsql doesn't work that way, so why would this? > *especially* with the %TYPE decorator.
Yeah. The %TYPE decorator doesn't work like that in the core parser either: when you use it, the referenced type is determined immediately and then it's just as if you'd written that type name to begin with. I do not see a reason for any of these "type operators" to work differently.
Another analogy that might help make the point is
set search_path = a; create table myschema.tab(f1 mytype); set search_path = b;
If there are types "mytype" in both schemas a and b, is myschema.tab.f1 now of type b.mytype? No. The meaning of the type reference is determined when the command executes, and then you're done.
This is valid for PostgreSQL. I am not sure if it is true in Oracle, if %TYPE means only reference to type, or %TYPE holds reference to original object - and when you change the original object, then the function is invalidated.
Using %TYPE with create time only semantic has not big practical benefit. But when %TYPE enforce all life dependency, then I have guaranteed so change on original object will be propagated to depend object. With all advantages and disadvantages.
Postgres uses %TYPE in create time only semantic - but it is not big issue in PLpgSQL, because the creation time there is often - every first execution in session.
The usage of %TYPE outer PL/pgSQL is probably only in FK. But nothing similar is in standard, and I don't see a reason, why we should to implement it. In this moment I don't see any important use case.
