Re: BUG #15960: ON CONFLICT Trying accessing to variables

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

In response to

Responses

Browse pgsql-bugs by date

  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