Re: Fix bug in handling of dropped columns in pltcl triggers
От | Michael Paquier |
---|---|
Тема | Re: Fix bug in handling of dropped columns in pltcl triggers |
Дата | |
Msg-id | CAB7nPqTggoAOxkYWQrzpZwdiwCMXGWGQ06-6X6uNHo85eFAXGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Fix bug in handling of dropped columns in pltcl triggers (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Fix bug in handling of dropped columns in pltcl triggers
|
Список | pgsql-hackers |
On Tue, Nov 1, 2016 at 4:17 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > While reviewing code coverage in pltcl, I uncovered a bug in trigger > function return handling. If you returned the munged name of a dropped > column, that would silently be ignored. It would be unusual to hit this, > since dropped columns end up with names like ".......pg.dropped.2.......", > but since that's still a legitimate name for a column silently ignoring it > seems rather bogus. It seems to me that this patch breaks $TG_relatts and what existing applications would except from it: <varlistentry> <term><varname>$TG_relatts</varname></term> <listitem> <para> A Tcl list of the table column names, prefixed with an empty list element. So looking up a columnname in the list with <application>Tcl</>'s <function>lsearch</> command returns the element's number starting with 1 for the firstcolumn, the same way the columns are customarily numbered in <productname>PostgreSQL</productname>. (Empty list elements also appear in the positions of columns that have been dropped, so that the attribute numberingis correct for columns to their right.) </para> </listitem> </varlistentry> As this is a behavior present since 2004, it does not sound wise to change it. -- Michael
В списке pgsql-hackers по дате отправления: