Re: BUG #15960: ON CONFLICT Trying accessing to variables
От | Andres Freund |
---|---|
Тема | Re: BUG #15960: ON CONFLICT Trying accessing to variables |
Дата | |
Msg-id | 20190815194213.hskbzb3vcpij5tiy@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #15960: ON CONFLICT Trying accessing to variables (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #15960: ON CONFLICT Trying accessing to variables
|
Список | pgsql-bugs |
Hi, On 2019-08-15 10:09:14 -0700, Peter Geoghegan wrote: > On Thu, Aug 15, 2019 at 10:05 AM Andres Freund <andres@anarazel.de> wrote: > > I'm not sure I quite buy that. There is no actual ambiguity here. I don't buy the variable referencing a constant -that'd not correctly work for subsequent uses of the statement if the variable differs - don't think we'd have replacingetc set up. Nor do I think we would even evaluate The variable/param. > > If we were going to fix this, then it would probably be because of the > issue around it working inconsistently when the variable differs over > multiple calls. That's something that we've heard about at least once > before. I'm not excited about fixing the ambiguity issue. Well, I think it'd currently error out in many cases (presumably once we're over the 5 executions limit or such?), so that'd prevent the error from actually causing problems like that. > > Seems like it's more a question of preventing the hook from resolving things at that point? > > I don't know. Seems like we'd just need a new EXPR_KIND_*, maybe EXPR_KIND_ARBITER_EXPRESSION, which plpgsql's column hook would just ignore. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: