Re: bloated heapam.h

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bloated heapam.h
Date: 2008-05-10 19:26:16
Message-ID: 20080510192615.GA9094@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-10 21:10:45 Re: bloated heapam.h
Previous Message David Fetter 2008-05-10 18:25:16 Re: Posting to hackers and patches lists