Re: BUG #16644: null value for defaults in OLD variable for trigger
От | Amit Langote |
---|---|
Тема | Re: BUG #16644: null value for defaults in OLD variable for trigger |
Дата | |
Msg-id | CA+HiwqFy=y-gDf3bxwpYQfEfz77nTB=NLWKH-umsEijCHinCyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16644: null value for defaults in OLD variable for trigger (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Mon, Oct 26, 2020 at 12:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Amit Langote <amitlangote09@gmail.com> writes: > > On Mon, Oct 26, 2020 at 5:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Moreover, it's more correct, even disregarding the problem > >> at hand, because the tlist isn't a perfectly accurate depiction of > >> the relation rowtype: ExecCleanTypeFromTL will not derive the correct > >> info for dropped columns. > > > Hmm, I don't understand. Isn't it the planner's job to make the > > targetlist correctly account for dropped columns; what > > expand_targetlist() does? > > Yes, there are columns in the tlist to match them, but ExecCleanTypeFromTL > cannot mark those columns as "attisdropped". Ah, okay. > The column data type > likely won't be right either. The latter shouldn't matter, if the > column is being filled with a null ... but I'm a bit surprised that > we've gotten away this long with not being honest about attisdropped. Yeah, I guess most places downstream of ExecModifyTable() seem to rely on getting that information indirectly via the isnull flag of the tuple itself. -- Amit Langote EDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: