From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bloated heapam.h |
Date: | 2008-05-10 21:10:45 |
Message-ID: | 6911.1210453845@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> The one that makes a bit more sense is a new syncscan.h. And there are
> a lot of things in heapam.h that actually correspond to tuple
> manipulation (heap_form_tuple and so on), so perhaps a new header file
> would be appropriate, but there's already htup.h which contains
> tuple-related stuff.
After actually looking at the header a bit ...
+1 for moving fastgetattr, heap_getattr, and the heaptuple.c functions
to htup.h. I don't see any big gain from relocating the other stuff;
it seems to largely all use about the same set of typedefs.
It looks to me actually that a large part of your complaint is that
heapam.h #includes more than it has to. Have you tried just cutting its
#include list to the minimum needed to compile its function declarations?
Likely this would force more #includes in .c files but I don't object
to that. (I might be wrong, but I believe that Bruce's script for
removing "unnecessary" #includes is not bright enough to make such
tradeoffs, so it'd let bloated #include lists in headers survive.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2008-05-10 21:15:10 | Re: Setting a pre-existing index as a primary key |
Previous Message | Alvaro Herrera | 2008-05-10 19:26:16 | Re: bloated heapam.h |