Обсуждение: don't include tableam.h in nbtree.h

I noticed that nbtree.h includes tableam.h.  This seems rather random
and unnecessary.  This patch removes it and fixes fallout, which is
pretty minimal.  We do need to add a forward declaration of struct
TM_IndexDeleteOp (whose full definition appears in tableam.h) so that
_bt_delitems_delete_check()'s declaration can use it.

Also remove xlogreader.h, which is AFAICS 100% useless here.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

Hi,

On Tue, Aug 05, 2025 at 01:09:57PM +0200, Álvaro Herrera wrote:
> I noticed that nbtree.h includes tableam.h.  This seems rather random
> and unnecessary.  This patch removes it and fixes fallout, which is
> pretty minimal.  We do need to add a forward declaration of struct
> TM_IndexDeleteOp (whose full definition appears in tableam.h) so that
> _bt_delitems_delete_check()'s declaration can use it.

I think that makes sense.

index 1127597bb60..8282055ebca 100644
--- a/contrib/btree_gist/btree_bool.c
+++ b/contrib/btree_gist/btree_bool.c
@@ -6,6 +6,7 @@
 #include "btree_gist.h"
 #include "btree_utils_num.h"
 #include "utils/sortsupport.h"
+#include "utils/rel.h"

There is several places like this one where the new include is not ordered based
on the ASCII values (while it looks like it should be according to 7e735035f2).

Shouldn't that be the case? If so, PFA a patch to apply on top of your v1.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

On 2025-Aug-05, Bertrand Drouvot wrote:

> I think that makes sense.

Thanks for looking!

> index 1127597bb60..8282055ebca 100644
> --- a/contrib/btree_gist/btree_bool.c
> +++ b/contrib/btree_gist/btree_bool.c
> @@ -6,6 +6,7 @@
>  #include "btree_gist.h"
>  #include "btree_utils_num.h"
>  #include "utils/sortsupport.h"
> +#include "utils/rel.h"
> 
> There is several places like this one where the new include is not ordered based
> on the ASCII values (while it looks like it should be according to 7e735035f2).

Oh yeah, that's been the intention for many years.  This was just me
failing to sort properly ...  thanks for the patch, I included it and
pushed.

Cheers,

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/