Possible fault with resolve column name (plpgsql)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t44825psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:43 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t44825_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t44825_1 && git checkout t44825_1Patchset v1 (message #1) is on t44825_1
Hi,
Found by llvm scan build.
Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
resolve_column_ref
Proceed?
regards,
Ranier Vilela
Ranier Vilela <ranier.vf@gmail.com> writes:
Found by llvm scan build.
Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
resolve_column_ref
This is somewhere between pointless and counterproductive. colname won't
be used unless the switch has set nnames_field (and the identified number
of names matches that). If that logic somehow went wrong, I'd *want*
the later strcmp to dump core, not possibly give a false match.
regards, tom lane
Em qui., 16 de set. de 2021 às 17:05, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
Found by llvm scan build.
Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
resolve_column_refThis is somewhere between pointless and counterproductive.
Not if you've ever used llvm scan, but it's pretty accurate in identifying
what the condition might occur.
colname won't
be used unless the switch has set nnames_field (and the identified number
of names matches that).
13
← <#Path12>
Assuming field 'type' is equal to T_String
→ <#Path14>
22
← <#Path21>
Assuming 'nnames' is equal to 'nnames_field'
→ <#Path23>
If that logic somehow went wrong, I'd *want*
the later strcmp to dump core, not possibly give a false match.
In this case, strcmp will fail silently, without any coredump.
If we have a record, and the field is T_String, always have a true match?
regards,
Ranier Vilela