I think that is my point though? Since the ON CONFLICT parameters are not variables, it should never cause a concern...
butin this case, thats exactly what is happening. Its almost being interpreted as though the variable is being replaced
withits value. I.e. ON CONFLICT ('awe') which of course is not going to work. The way it should work should be
identicalto other parts of the query which are the same condition and don't concern with whether to interpret as
variableor column, because they can only be column.
> On Jan 5, 2022, at 5:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alexi Theodore <alexitheodore@gmail.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
shortsynopsis is that when using "#variable_conflict use_variable" in a function or procedure, the correct choice of
variablevs 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
