[19.0][FIX] stock_account: fix syntax error in stock_move_value() post-migration on PostgreSQL 13

[zbynekdrlik]

Bug

stock_move_value() in openupgrade_scripts/scripts/stock_account/19.0.1.1/post-migration.py
builds an aggregate subquery with a bare-word column alias (no AS) immediately
after the sum() call:

UPDATE stock_move
SET value=aggregated_values.value
FROM (
    SELECT
    move_id, sum(value) value
    FROM
    product_value
    GROUP BY move_id
) aggregated_values
WHERE aggregated_values.move_id=stock_move.id

PostgreSQL 13 rejects this as a syntax error:

ERROR:  syntax error at or near "value"
LINE 5:     move_id, sum(value) value
                                ^

This is PostgreSQL-version dependent, not data-dependent — the same statement
runs fine on PostgreSQL 16 (confirmed below), which makes the bug easy to miss
when re-testing on a newer engine. Any 18.0 -> 19.0 migration of a database
with stock_account installed, run against a PostgreSQL 13 backend, hits this
unconditionally partway through the post-migration step.

Repro (real, not assumed)

Against a PostgreSQL 13.23 database used for an actual 15.0 -> 19.0
OpenUpgrade migration chain, inside BEGIN; ... ROLLBACK; so nothing persisted:

BEGIN;
UPDATE stock_move
SET value=aggregated_values.value
FROM (
    SELECT
    move_id, sum(value) value
    FROM
    product_value
    GROUP BY move_id
) aggregated_values
WHERE aggregated_values.move_id=stock_move.id;
ROLLBACK;

BEGIN
ERROR:  syntax error at or near "value"
LINE 5:     move_id, sum(value) value
                                ^
ROLLBACK

The same statement, patched (agg_value alias), against the same database,
in the same rollback-guarded transaction:

BEGIN
UPDATE 3
ROLLBACK

A separate check against a PostgreSQL 16 database did not reproduce the
error — confirming this is version-dependent, not something wrong with the
data.

Fix

Alias the aggregate column explicitly (agg_value) and reference the aliased
name in the outer UPDATE ... SET, instead of relying on a bare column name
that happens to collide with the outer table's own value column:

 UPDATE stock_move
-SET value=aggregated_values.value
+SET value=aggregated_values.agg_value
 FROM (
     SELECT
-    move_id, sum(value) value
+    move_id, sum(value) AS agg_value
     FROM
     product_value
     GROUP BY move_id
 ) aggregated_values
 WHERE aggregated_values.move_id=stock_move.id

Test

python3 -m py_compile on the patched file compiles clean. ruff check /
ruff format --check on the patched file both pass with no findings. The
patched SQL statement was run against the same PostgreSQL 13.23 database
used for the repro above (again inside BEGIN;...ROLLBACK;) and completed
with UPDATE 3, no error.

No functional/behavioral test suite covers this migration script beyond
OpenUpgrade's own migration-execution smoke test, so this fix was verified
by direct SQL execution against a real PostgreSQL 13 database reproducing
the exact failure, per the repro above — not merely reasoned about.

[pedrobaeza]

Although using so old PG version in 19 is not recommended, this works for all the PG versions, so it's harmless.