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 outp
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. Un
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 miss
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 Pa
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
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 i
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 whe
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
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 see
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 sense
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
know
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 Transacti
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
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 sho
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 tha
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 attribut
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 he
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
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
fun
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 h
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 fo
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
f
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 examp
23 matches
Mail list logo
