Re: bloated heapam.h - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: bloated heapam.h
Date
Msg-id 20080510192615.GA9094@alvh.no-ip.org
Whole thread Raw
In response to Re: bloated heapam.h  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: bloated heapam.h  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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), but they force some other
>> files into including heapam.h to get their prototypes.  I think this is
>> a mistake; I propose splitting those prototypes to their own files, and
>> #including those as appropriate.
>>
>> Objections?
>
> I have similar thing in my TODO list. See my patch from March commit fest 
> and discussion. I need solve two main issues - remove postgres.h from 
> binaries and keep history of structures (for pg_upgrade project).

Yeah, I remember that.  Is there any progress on that front?

BTW I noticed that I was a bit careless in the description.  rewriteheap
already has its own rewriteheap.h file; and there's no point at all in
separating pruneheap.c declarations into another file.

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.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Posting to hackers and patches lists
Next
From: Tom Lane
Date:
Subject: Re: bloated heapam.h