]> mop.ddnsfree.com - git repositories - brisk.git/commit
postgresql 10+ compatibility (debian 13 ships 17)
authorMatteo Nastasi <nastasi@alternativeoutput.it>
Sun, 13 Sep 2026 10:31:03 +0000 (12:31 +0200)
committerMatteo Nastasi <nastasi@alternativeoutput.it>
Sun, 13 Sep 2026 10:31:03 +0000 (12:31 +0200)
commitb2a1d809c0c4980da9fe53faa8a0a15cf9e506ed
tree7ce148a0ac82701a5fe11c26b324282b1c8bc526
parent4e90dc8ae4eb25bd07be1656cbff6ee92ddb7e87
postgresql 10+ compatibility (debian 13 ships 17)

Found by running the code against a real database: neither the lint nor
loading the sources could see them.

UPDATE ... SET (col) = (val)
Since postgresql 10 the parenthesised form on a SINGLE column is an error
("source for a multiple-column UPDATE item must be a sub-SELECT or ROW()
expression"): (val) is not a ROW but a parenthesised expression. The multi
column form is still valid, checked on the server: of the 11 parenthesised
UPDATEs in the project only 4 need fixing, the other 7 are left alone.

  dbase_pgsql.phh  SET (lintm)     user_update_login_time()
                   SET (pass)      user_update_passwd()
                   SET (tos_vers)  user_tos_update()
                   SET (game_cnt)  bin5_points_save()
  sql.d/085-tourn-update.sql  two SET (name)

This is not a consequence of the php 8 port: they were already broken on any
postgresql >= 10. They cover password recovery and the acceptance of the
terms of service.

int2four()
The literal 0xffffffff00000000 is above PHP_INT_MAX, so php treats it as a
float and the or converts it back to int: since 8.1 that is the "Implicit
conversion from float to int loses precision" deprecation, emitted on every
call (the function sits in the self-registration check path). Rewritten with
~0xffffffff, same bit pattern but an integer. Identical values, compared on
0, 1, 0x7fffffff, 0x80000000, 0xc0a80001 and 0xffffffff.

Checked against a real database (postgresql 17, schema rebuilt from scratch
with sql/builder.sh: 18 files, 12 tables, 6 views, 0 errors): connection,
queries, user_add, login_exists, getrecord_bylogin, the three fixed UPDATEs,
the two multi column ones, transactions and selfreg. No warnings, no
deprecations. The error branch of BriskDB::query() was checked too, by
forcing a query on a non existing table: it logs with pg_last_error(), does
not raise a TypeError, and the connection survives the recovery.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014M1jiEq9cHdE5SE5j6vFuE
sql/sql.d/085-tourn-update.sql
web/Obj/brisk.phh
web/Obj/dbase_pgsql.phh