Re: ON CONFLICT issues around whole row vars,
От | Andres Freund |
---|---|
Тема | Re: ON CONFLICT issues around whole row vars, |
Дата | |
Msg-id | 20150929152447.GM5702@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: ON CONFLICT issues around whole row vars, (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: ON CONFLICT issues around whole row vars,
Re: ON CONFLICT issues around whole row vars, |
Список | pgsql-hackers |
On 2015-09-24 17:25:21 +0200, Andres Freund wrote: > Stuff I want to fix by tomorrow: > * Whole row var references to exclude > * wrong offsets for columns after dropped ones > * INSTEAD DO UPDATE for tables with oids > > Do you know of anything else? So, took a bit longer than "tomorrow. I fought for a long while with a mysterious issue, which turned out to be separate bug: The excluded relation was affected by row level security policies, which doesn't make sense. My proposal in this WIP patch is to make it a bit clearer that 'EXCLUDED' isn't a real relation. I played around with adding a different rtekind, but that's too heavy a hammer. What I instead did was to set relkind to composite - which seems to signal pretty well that we're not dealing with a real relation. That immediately fixes the RLS issue as fireRIRrules has the following check: if (rte->rtekind != RTE_RELATION || rte->relkind != RELKIND_RELATION) continue; It also makes it relatively straightforward to fix the system column issue by adding an additional relkind check to scanRTEForColumn's system column handling. WRT to the wholerow issue: There's currently two reasons we need a targetlist entry for excluded wholerow vars: 1) setrefs.c errors out without - that can relativley easily be worked around 2) ruleutils.c expects an entry in the child tlist. That could also be worked around, but it's a bit more verbose. I'm inclined to not go the pullup route but instead simply unconditionally add a wholerow var to the excluded tlist. Peter, what do you think? Andres
Вложения
В списке pgsql-hackers по дате отправления: