Re: Regression tests fail with tzdata 2024b

table setting for timezone. I guess I'll adjust our tests to not depend on upstream pg_regress timezone. -- Regards, Sven Klemm

Re: Regression tests fail with tzdata 2024b

anyway). > I was wondering whether the timezone used by pg_regress could be made configurable. -- Regards, Sven Klemm

Re: Regression tests fail with tzdata 2024b

ll break extensions tests using pg_regress for testing. We run our tests against multiple minor versions and this getting backported means our tests will fail with the next minor pg release. Is there a workaround available to make the timezone for pg_regress configurable without going into every test? Regards, Sven Klemm

[PATCH] Handle SK_SEARCHNULL and SK_SEARCHNOTNULL in HeapKeyTest

, Sven Klemm From 7ba786ebc065a27375dac9ced6d1928d0e8e5740 Mon Sep 17 00:00:00 2001 From: Sven Klemm Date: Sat, 22 Jun 2024 15:21:53 +0200 Subject: [PATCH] Handle SK_SEARCHNULL and SK_SEARCHNOTNULL in HeapKeyTest Change HeapKeyTest to not return false on SK_ISNULL but instead return a result

Re: [PATCH] Improve error message when trying to lock virtual tuple.

e assertions enabled and will produce the misleading `could not read block 0` error. I am aware that this not a postgres bug, but i think this error message is an improvement over the current situation. -- Regards, Sven Klemm

[PATCH] Improve error message when trying to lock virtual tuple.

an error in those extensions the resulting error is very misleading. -- Regards, Sven Klemm From c5ccbf2e9cb401a7e63e93cd643b4dfec8d92ab8 Mon Sep 17 00:00:00 2001 From: Sven Klemm Date: Mon, 17 Jun 2024 17:38:27 +0200 Subject: [PATCH] Improve error message when trying to lock virtual tuple

Re: Regression in PG14 LookupFuncName

> It was intentional, because all internal callers of LookupFuncName only > want to see functions. See the last few messages in the referenced > discussion thread: > > https://www.postgresql.org/message-id/flat/3742981.1621533210%40sss.pgh.pa.us Thank you for the clarification. -

Regression in PG14 LookupFuncName

Hi hackers, In PG12 and PG13 LookupFuncName would return procedures as well as functions while in PG14 since commit e56bce5d [0] it would disregard all procedures and not return them as match. Is this intended behaviour or an unintended side effect of the refactoring? Sven [0] https://github.co

Re: Fix dropped object handling in pg_event_trigger_ddl_commands

On Sun, Apr 18, 2021 at 2:12 PM Sven Klemm wrote: > when creating an event trigger for ddl_command_end that calls > pg_event_trigger_ddl_commands certain statements will cause the > trigger to fail with a cache lookup error. The error happens on > master, 13 and 12 I didnt test

Fix dropped object handling in pg_event_trigger_ddl_commands

meone more familiar with this code might have an idea for a better solution. Any thoughts? https://www.postgresql.org/message-id/CAMCrgp39V7JQA_Gc+JaEZV3ALOU1ZG=pwyk3odptq7f6z0j...@mail.gmail.com -- Regards, Sven Klemm From 4faf761528c735bd808e7ea4d9f356710e3a8ed0 Mon Sep 17 00:00:00 2001 From: Sven K

[PATCH] Allow CustomScan nodes to signal projection support

default and make it an opt out. But that would make the flag name notably different from the other flag names. Any opinions on the flag name and whether it should be opt in or opt out? -- Regards, Sven Klemm v1-0001-costumscan_projection_flag.patch Description: Binary data