Re: A problem with dump/restore of views containing whole row references
От | Andrew Dunstan |
---|---|
Тема | Re: A problem with dump/restore of views containing whole row references |
Дата | |
Msg-id | 4F9AC590.7@dunslane.net обсуждение исходный текст |
Ответ на | Re: A problem with dump/restore of views containing whole row references (Abbas Butt <abbas.butt@enterprisedb.com>) |
Ответы |
Re: A problem with dump/restore of views containing whole row references
|
Список | pgsql-hackers |
On 04/27/2012 12:02 PM, Abbas Butt wrote: > > > > However, is this a change we really want to make?: > > pg_get_triggerdef > > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > - CREATE TRIGGER modified_any BEFORE UPDATE OF a ON main_table > FOR EACH ROW WHEN (old.* IS DISTINCT FROM new.*) EXECUTE PROCEDURE > trigger_func('modified_any') > + > pg_get_triggerdef > > +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > + CREATE TRIGGER modified_any BEFORE UPDATE OF a ON main_table > FOR EACH ROW WHEN (old.*::main_table IS DISTINCT FROM > new.*::main_table) EXECUTE PROCEDURE trigger_func('modified_any') > > > Maybe we need to be a bit more selective about when the cast is > supplied. It's not adding any extra disambiguation (or clarity) here. > > > > I ran the regression and found that my patch is causing a diff in the > trigger test case, thats why I changed the expected output of the test > case accordingly. This is a side effect of the change I did to fix the > bug. > Right, what I'm asking is whether or not we actually want that side effect in all cases, and specifically in this case where it's clearly not necessary. cheers andrew
В списке pgsql-hackers по дате отправления: