Avoid is possible a expensive function call (src/backend/utils/adt/varlena.c)
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:t49276psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 11:07 PM.
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 t49276_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 t49276_1 && git checkout t49276_1Patchset v1 (message #1) is on t49276_1
Hi,
The function var_strcmp is a critical function.
Inside the function, there is a shortcut condition,
which allows for a quick exit.
Unfortunately, the current code calls a very expensive function beforehand,
which if the test was true, all the call time is wasted.
So, IMO, it's better to postpone the function call until when it is
actually necessary.
best regards,
Ranier Vilela
On Mon, 4 Mar 2024 at 18:39, Ranier Vilela <ranier.vf@gmail.com> wrote:
Hi,
The function var_strcmp is a critical function.
Inside the function, there is a shortcut condition,
which allows for a quick exit.Unfortunately, the current code calls a very expensive function beforehand, which if the test was true, all the call time is wasted.
So, IMO, it's better to postpone the function call until when it is actually necessary.
Thank you for your contribution.
I agree it would be better, but your current patch is incorrect,
because we need to check if the user has access to the locale (and
throw an error if not) before we return that the two strings are
equal.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
Em seg., 4 de mar. de 2024 às 14:54, Matthias van de Meent <
boekewurm+postgres@gmail.com> escreveu:
On Mon, 4 Mar 2024 at 18:39, Ranier Vilela <ranier.vf@gmail.com> wrote:
Hi,
The function var_strcmp is a critical function.
Inside the function, there is a shortcut condition,
which allows for a quick exit.Unfortunately, the current code calls a very expensive function
beforehand, which if the test was true, all the call time is wasted.
So, IMO, it's better to postpone the function call until when it is
actually necessary.
Thank you for your contribution.
I agree it would be better, but your current patch is incorrect,
because we need to check if the user has access to the locale (and
throw an error if not) before we return that the two strings are
equal.
I can't see any user validation at the function pg_newlocale_from_collation.
meson test pass all checks.
best regards,
Ranier Vilela
On Mon, Mar 04, 2024 at 03:08:03PM -0300, Ranier Vilela wrote:
I can't see any user validation at the function pg_newlocale_from_collation.
Matthias is right, look closer. I can see more than one check,
especially note the one related to the collation version mismatch that
should not be silently ignored.
meson test pass all checks.
Collations are harder to test because they depend on the environment
where the test happens, especially with ICU.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Mon, Mar 04, 2024 at 03:08:03PM -0300, Ranier Vilela wrote:
I can't see any user validation at the function pg_newlocale_from_collation.
Matthias is right, look closer. I can see more than one check,
especially note the one related to the collation version mismatch that
should not be silently ignored.
The fast path through that code doesn't include any checks, true,
but the point is that finding the entry proves that we made those
checks previously. I can't agree with making those semantics
squishy in order to save a few cycles in the exact-equality case.
regards, tom lane
Em seg., 4 de mar. de 2024 às 20:28, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Michael Paquier <michael@paquier.xyz> writes:
On Mon, Mar 04, 2024 at 03:08:03PM -0300, Ranier Vilela wrote:
I can't see any user validation at the function
pg_newlocale_from_collation.
Matthias is right, look closer. I can see more than one check,
especially note the one related to the collation version mismatch that
should not be silently ignored.The fast path through that code doesn't include any checks, true,
but the point is that finding the entry proves that we made those
checks previously. I can't agree with making those semantics
squishy in order to save a few cycles in the exact-equality case.
Robustness is a fair point.
best regards,
Ranier Vilela