Re: BUG #15960: ON CONFLICT Trying accessing to variables
От | Tom Lane |
---|---|
Тема | Re: BUG #15960: ON CONFLICT Trying accessing to variables |
Дата | |
Msg-id | 31082.1565906785@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15960: ON CONFLICT Trying accessing to variables (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #15960: ON CONFLICT Trying accessing to variables
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes: > 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: >>> 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. It's already using EXPR_KIND_INDEX_EXPRESSION, so I doubt you need a new exprkind; it'd be fine not to resolve plpgsql variables in CREATE INDEX too. Possibly the same could happen for some other exprkinds. But I'm not really sure that having the hook discriminate against particular exprkinds is a good idea, on two grounds: 1. It introduces user-visible inconsistency. Despite the OP's opinion, I am not convinced that having "id" behave differently here than it would elsewhere is a good thing. 2. It seems like an inevitable source of future bugs, when somebody changes something in a way that makes it desirable to resolve plpgsql variables in a particular exprkind. Yeah, that most likely means they should have split that exprkind in two, but this is the sort of action at a distance that's very unlikely to get noticed until too late. Maybe it'd be a net positive despite these objections, but I do not think it's a clear-cut win. regards, tom lane
В списке pgsql-bugs по дате отправления: