[PATCH] Handle SK_SEARCHNULL and SK_SEARCHNOTNULL in HeapKeyTest
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:t49885psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 21, 2026 at 04:32 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 t49885_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 t49885_1 && git checkout t49885_1Patchset v1 (message #1) is on t49885_1
Hello,
This patches changes the HeapKeyTest macro to add handling for SK_SEARCHNULL
and SK_SEARCHNOTNULL. While currently no core codes uses these ScanKey flags
it would be useful for extensions if it was supported so extensions
dont have to implement
handling for those by themself.
--
Regards, Sven Klemm
Hi,
This patches changes the HeapKeyTest macro to add handling for SK_SEARCHNULL
and SK_SEARCHNOTNULL. While currently no core codes uses these ScanKey flags
it would be useful for extensions if it was supported so extensions
dont have to implement
handling for those by themself.
As I recall, previously it was argued that changes like this should
have some use within the core [1]https://commitfest.postgresql.org/42/4180/.
Can you think of any such use?
[1]: https://commitfest.postgresql.org/42/4180/
--
Best regards,
Aleksander Alekseev
On Mon, 1 Jul 2024 at 15:48, Aleksander Alekseev
<aleksander@timescale.com> wrote:
As I recall, previously it was argued that changes like this should
have some use within the core [1].
I don't see that argument anywhere in the thread honestly. I did see
heiki asking why it would be useful for extensions, but that was
answered there.
Hi,
As I recall, previously it was argued that changes like this should
have some use within the core [1].I don't see that argument anywhere in the thread honestly. I did see
heiki asking why it would be useful for extensions, but that was
answered there.
The referred patch was rejected at first because it didn't modify
nodeSeqScan.c to make use of the change within the core.
I'm not saying this is necessarily applicable to this particular patch
or that this is a general rule though.
--
Best regards,
Aleksander Alekseev
On Tue, 2 Jul 2024 at 10:15, Aleksander Alekseev
<aleksander@timescale.com> wrote:
The referred patch was rejected at first because it didn't modify
nodeSeqScan.c to make use of the change within the core.
I guess we interpret Heikis email differently. I read it as: "If this
improves performance, then let's also start using it in core. If not,
why do extensions need it?" And I think you quite clearly explained
that even if perf is not better, then the usability for extensions
that don't want to use SPI is better.
I don't think Heiki meant his response as not using it in core being a
blocker for the patch. But maybe my interpretation of his response is
incorrect.