Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types
От | Tom Lane |
---|---|
Тема | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
Дата | |
Msg-id | 19355.1458171557@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for
composite types
Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: