Re: [HACKERS] bloated heapam.h

2008-05-15 Thread Zdenek Kotala
Alvaro Herrera wrote: Zdenek Kotala wrote: Alvaro Herrera napsal(a): I try to play with lint now if it gets better results. Ok, good. Hmm, It generates a lot of unnecessary includes in *.c files. I have checked only couple of them and it seems that they are really unnecessary. A attach

Re: [HACKERS] bloated heapam.h

2008-05-13 Thread Alvaro Herrera
Zdenek Kotala wrote: Alvaro Herrera napsal(a): I try to play with lint now if it gets better results. Ok, good. Hmm, It generates a lot of unnecessary includes in *.c files. I have checked only couple of them and it seems that they are really unnecessary. A attach output. Unfortunately,

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Zdenek Kotala
Alvaro Herrera wrote: Alvaro Herrera wrote: Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which is a change you had objected to previously :-( However, it seems the right fix is to move BufferGetPageSize and BufferGetPage from bufpage.h to bufmgr.h. +1 It makes more

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which is a change you had objected to previously :-( http://archives.postgresql.org/pgsql-patches/2008-04/msg00149.php Hmm. I did notice that the patch seemed to

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Alvaro Herrera
Zdenek Kotala wrote: Alvaro Herrera wrote: (Digging further, it seems like bufpage.h should also include transam.h in order to get TransactionIdIsNormal ... I start to wonder how many problems of this nature we have on our headers. Without having a way to detect whether the defined macros

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Zdenek Kotala
Alvaro Herrera napsal(a): Zdenek Kotala wrote: Alvaro Herrera wrote: (Digging further, it seems like bufpage.h should also include transam.h in order to get TransactionIdIsNormal ... I start to wonder how many problems of this nature we have on our headers. Without having a way to detect

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Alvaro Herrera
Zdenek Kotala wrote: Alvaro Herrera napsal(a): Zdenek Kotala wrote: I attached script which should check it. In first step it runs C preprocessor on each header (postgres.h is included as well). The output from first step is processed again with preprocessor and define.h is included.

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Zdenek Kotala
Alvaro Herrera napsal(a): Zdenek Kotala wrote: Alvaro Herrera napsal(a): Zdenek Kotala wrote: I attached script which should check it. In first step it runs C preprocessor on each header (postgres.h is included as well). The output from first step is processed again with preprocessor and

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Alvaro Herrera
Zdenek Kotala wrote: Alvaro Herrera napsal(a): Well, then it is not working, because transam.h is missing from bufpage.h ... It tried catch problems with defines not with datatypes. If you mean that TransactionID is not defined. No, I mean that TransactionIdIsNormal() is used in

Re: [HACKERS] bloated heapam.h

2008-05-12 Thread Zdenek Kotala
Alvaro Herrera napsal(a): I try to play with lint now if it gets better results. Ok, good. Hmm, It generates a lot of unnecessary includes in *.c files. I have checked only couple of them and it seems that they are really unnecessary. A attach output. Unfortunately, it does not detect

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: So here's a patch (includes the #ifndef FRONTEND hack in htup.h.) I like this except for the #ifndef FRONTEND hack --- you're going to need to fix that before applying. I'm good with doing that by pushing the system attribute numbers into a separate

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: So here's a patch (includes the #ifndef FRONTEND hack in htup.h.) I like this except for the #ifndef FRONTEND hack --- you're going to need to fix that before applying. I'm good with doing that by pushing the system attribute

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Alvaro Herrera
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: So here's a patch (includes the #ifndef FRONTEND hack in htup.h.) I like this except for the #ifndef FRONTEND hack --- you're going to need to fix that before applying. I'm good with doing that by pushing

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Alvaro Herrera
Alvaro Herrera wrote: Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which is a change you had objected to previously :-( However, it seems the right fix is to move BufferGetPageSize and BufferGetPage from bufpage.h to bufmgr.h. (Digging further, it seems like bufpage.h

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which is a change you had objected to previously :-( http://archives.postgresql.org/pgsql-patches/2008-04/msg00149.php Hmm. I did notice that the patch seemed to need to add bufmgr.h

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: However, it seems the right fix is to move BufferGetPageSize and BufferGetPage from bufpage.h to bufmgr.h. That sounds sane if it fixes the problem. (Digging further, it seems like bufpage.h should also include transam.h in order to get

Re: [HACKERS] bloated heapam.h

2008-05-11 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: However, it seems the right fix is to move BufferGetPageSize and BufferGetPage from bufpage.h to bufmgr.h. That sounds sane if it fixes the problem. Actually it's not, because bufmgr.h does not include bufpage.h, and it knows

Re: [HACKERS] bloated heapam.h

2008-05-10 Thread Zdenek Kotala
Alvaro Herrera napsal(a): Others are more conflictive. For example syncscan.c is keeping the prototypes for its own functions on heapam.h. Also pruneheap.c and rewriteheap.c. As a result, not only themselves need to include heapam.h (without any other need for it), but they force some other

Re: [HACKERS] bloated heapam.h

2008-05-10 Thread Alvaro Herrera
Zdenek Kotala wrote: Alvaro Herrera napsal(a): Others are more conflictive. For example syncscan.c is keeping the prototypes for its own functions on heapam.h. Also pruneheap.c and rewriteheap.c. As a result, not only themselves need to include heapam.h (without any other need for it),

Re: [HACKERS] bloated heapam.h

2008-05-10 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] 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

Re: [HACKERS] bloated heapam.h

2008-05-10 Thread Alvaro Herrera
Tom Lane wrote: +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. Ultimately that was my conclusion too. I tried moving the heaptuple.c

Re: [HACKERS] bloated heapam.h

2008-05-10 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Apparently the reason for pg_dump.c to need htup.h is getAttrName which needs system columns' attribute numbers. Of course, the first thing that comes to mind is that we should fix pg_dump to not require that header in the first place. Perhaps we can

[HACKERS] bloated heapam.h

2008-05-09 Thread Alvaro Herrera
Hi, I noticed heapam.h is included in way too many places. This is bad IMHO because heapam.h itself includes a lot of other headers. A lot of these are easy to fix; the source files just need to include some other headers. Standard cleanup, I don't think anybody would object to that. For