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
