Re: Bug report: variable_conflict + ON CONFLICT

I think that is my point though? Since the ON CONFLICT parameters are not variables, it should never cause a concern... but in this case, thats exactly what is happening. Its almost being interpreted as though the variable is being replaced with its value. I.e. ON CONFLICT ('awe') which of course is not going to work. The way it should work should be identical to other parts of the query which are the same condition and don't concern with whether to interpret as variable or column, because they can only be column.

> On Jan 5, 2022, at 5:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alexi Theodore <alexitheodore(at)gmail(dot)com> writes:
>> I'd like to report what I think is a bug. I've put together a script which highlights things pretty clearly. The short synopsis is that when using "#variable_conflict use_variable" in a function or procedure, the correct choice of variable vs column name is done everywhere (that I know of) except in the ON CONFLICT (<column name>) part of an INSERT statement. That one part only seems to not follow the conflict resolution pattern.
>
> The names in ON CONFLICT are not values, and it would not make
> sense to substitute plpgsql variable values for them. A related
> example is that if you write INSERT INTO t (a,b) VALUES (1,2),
> none of t, a, or b are candidates to be replaced by plpgsql
> variables.
>
> regards, tom lane