From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | anton(dot)dutov(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15960: ON CONFLICT Trying accessing to variables |
Date: | 2019-08-15 19:42:13 |
Message-ID: | 20190815194213.hskbzb3vcpij5tiy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)anarazel(dot)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 replacing etc 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
From | Date | Subject | |
---|---|---|---|
Next Message | Piotr Gabriel Kosinski | 2019-08-15 21:33:20 | Segmentation fault during update inside ExecBRUpdateTriggers |
Previous Message | Tom Lane | 2019-08-15 19:23:31 | Re: BUG #15913: Could not open relation with oid on PL/pgSQL method referencing temporary table that got recreated |