Re: BUG #15533: error on upsert when used in a fuction and a function parameter has the same name as the column
От | Andrew Gierth |
---|---|
Тема | Re: BUG #15533: error on upsert when used in a fuction and a function parameter has the same name as the column |
Дата | |
Msg-id | 87y399lcfz.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: BUG #15533: error on upsert when used in a fuction and a functionparameter has the same name as the column (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: BUG #15533: error on upsert when used in a fuction and a functionparameter has the same name as the column
|
Список | pgsql-bugs |
>>>>> "Pavel" == Pavel Stehule <pavel.stehule@gmail.com> writes: Pavel> I am strongly sure, so current default is best and any change of Pavel> this behave (it is simply - just use #option) is strongly wrong. I don't buy it; I call this a bug. Here's why: in an ON CONFLICT (col) clause, the (col) is not a list of expressions or even really a list of columns, what it is is an index definition (i.e. the same thing that would appear in CREATE INDEX). One consequence of this is that _qualified_ column names, which are a usual solution to variable name vs column conflicts, are not allowed here. There is already special processing done on the clause for this reason (the hiding of other tables that might be visible at this point in the query), and I would say that this simply doesn't go far enough and that parameters should be hidden too (by suppressing the columnref hooks while the arbiter clause is being analyzed). -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: