On Thu, Jan 7, 2021 at 10:55 AM Pavel Stehule <pavel.steh...@gmail.com> wrote:
>> Again, if this is narrowly confined to assignment into set query
>> operations, maybe this is not so bad. But is it?
>
> PLpgSQL_Expr: opt_target_list
> <--><--><-->from_clause where_clause
> <--><--><-->group_clause having_clause window_clause
> <--><--><-->opt_sort_clause opt_select_limit opt_for_locking_clause
> <--><--><--><-->{
>
> So SELECT INTO and assignment are not fully compatible now.
OK. Well, I went ahead and checked the code base for any suspicious
assignments that might fall out of the tightened syntax. It was
cursory, but didn't turn up anything obvious. So I'm going to change
my position on this.
My feedback would be to take backwards compatibility very seriously
relating to language changes in the future, and to rely less on
documentation arguments as it relates to change justification. The
current behavior has been in place for decades and is therefore a de
facto standard. Change freedom ought to be asserted in scenarios
where behavior is reserved as undefined or is non standard rather than
assumed. Rereading the development thread, it seems a fairly short
timeframe between idea origination and commit, and hypothetical
impacts to existing code bases was not rigorously assessed. I guess
it's possible this may ultimately cause some heartburn but it's hard
to say without strong data to justify that position.
Having said all of that, I'm very excited about the array assignment
improvements and investment in this space is very much appreciated. .
merlin
