On Mon, Apr 18, 2016 at 5:36 AM, Alex Bolenok <quassnoi@gmail.com> wrote:
> I realize there is an explanation to that (it's the way it's programmed,
> after all), and that might be not a bug worthy enough to fix (however,
> there are people actually affected by it, see here:
> http://stackoverflow.com/questions/36656643/is-variable-conflict-use-vari=
able-not-working-with-on-conflict-clause-of-upsert ),
> but it's clearly a bug in my opinion.
>
=E2=80=8BThat SO post is not convincing - though I don't know if the "tname=
" in the
ON CONFLICT clause can be somehow prefixed so that there is no conflict.
As written, there is a conflict between the table column and the function
parameter and, as instructed, PostgreSQL is using the variable which then
makes the ON CONFLICT clause - as executed - one that does not match
anything in the system.
I'm not particularly concerned with user-space code that uses that pragma.
Unless you are prepared to explain in great depth the hazards of the
current behavior, and probably more importantly the value in some
alternative behavior I'd suggest accepting the fact that this behavior is
precisely how functions work and move on. Just screaming "its a bug" is
not getting us anywhere.
It is possible to want to write a function that parameterizes the predicate
portion of the ON CONFLICT clause - i.e., one that when called with the
appropriate argument will find a match and resolve properly. Maybe someone
can provide an example that would work since right now I'm out of time.
So, your original premise is wrong one its face - while likely having
minimal practical use the function as written could succeed with the right
pre-conditions.
David J.