Re: splitting htup.h - Mailing list pgsql-hackers

Excerpts from Tom Lane's message of mar ago 28 17:27:51 -0400 2012:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > This patch is mainly doing four things:
>
> > 1. take some typedefs and the HeapTupleData struct definition from
> > access/htup.h, and put them in access/tupbasics.h.  This new file is
> > used as #include in all headers instead of htup.h.
>
> > I'm unsure about the "tupbasics.h" file name.  I'm open to better ideas.
>
> I'd be inclined to keep the name "htup.h" for the more widely used file,
> and invent a new name for what we're splitting out of it.

Meh.  When seen in that light, it makes a lot of sense.  I was actually
thinking it the other way around.

> This should
> reduce the number of changes needed, not only in our code but third
> party code.  Not sure if the new file could sanely be called
> "htup_private.h"; it seems a bit widely used for that.  Maybe "heap.h"?

Not sure I really like heap.h, but let's put that aside for a moment.

> Also, is there any reason to consider just moving those defs into
> heapam.h, instead of inventing a new header?  I'm not sure if there's
> any principled distinction between heap.h and heapam.h, or any
> significant differences between their sets of consumers.

To test this idea, I created a separate "scandesc.h" file that contains
struct declarations for HeapScanDesc and IndexScanDesc, and included
that one into execnodes.h instead of heapam.h and genam.h.  After fixing
the fallout in the .c files, it turns out that heapam.h is used by 116
files (some of them through relscan.h or hio.h).  Per my previous count,
heap.h would be used by 182 files.

So here's a list that depends on heap.h but not heapam.h (the reverse
is obviously empty because heapam.h itself depends on heap.h).  So I'm
inclined to keep both files separate.

./access/common/heaptuple.c
./access/common/reloptions.c
./access/common/tupconvert.c
./access/common/tupdesc.c
./access/gin/gininsert.c
./access/gist/gistbuild.c
./access/heap/visibilitymap.c
./access/nbtree/nbtsort.c
./access/nbtree/nbtxlog.c
./access/spgist/spginsert.c
./access/transam/rmgr.c
./access/transam/twophase.c
./access/transam/xlog.c
./access/transam/xlogfuncs.c
./bootstrap/bootparse.c
./catalog/indexing.c
./catalog/namespace.c
./commands/variable.c
./executor/execAmi.c
./executor/execQual.c
./executor/execTuples.c
./executor/functions.c
./executor/nodeAgg.c
./executor/nodeHash.c
./executor/nodeHashjoin.c
./executor/nodeSetOp.c
./executor/nodeSubplan.c
./executor/nodeWindowAgg.c
./executor/spi.c
./executor/tstoreReceiver.c
./foreign/foreign.c
./nodes/tidbitmap.c
./optimizer/path/costsize.c
./optimizer/plan/planagg.c
./optimizer/plan/planner.c
./optimizer/plan/subselect.c
./optimizer/util/clauses.c
./parser/parse_coerce.c
./parser/parse_func.c
./parser/parse_oper.c
./parser/parse_type.c
./snowball/dict_snowball.c
./storage/freespace/freespace.c
./storage/lmgr/predicate.c
./storage/page/bufpage.c
./tcop/fastpath.c
./tcop/utility.c
./tsearch/ts_selfuncs.c
./tsearch/wparser.c
./utils/adt/acl.c
./utils/adt/arrayfuncs.c
./utils/adt/array_selfuncs.c
./utils/adt/array_typanalyze.c
./utils/adt/datetime.c
./utils/adt/format_type.c
./utils/adt/genfile.c
./utils/adt/json.c
./utils/adt/lockfuncs.c
./utils/adt/pg_locale.c
./utils/adt/pgstatfuncs.c
./utils/adt/rangetypes_selfuncs.c
./utils/adt/rowtypes.c
./utils/adt/trigfuncs.c
./utils/adt/tsgistidx.c
./utils/adt/varbit.c
./utils/adt/varchar.c
./utils/adt/varlena.c
./utils/cache/inval.c
./utils/cache/lsyscache.c
./utils/cache/syscache.c
./utils/fmgr/fmgr.c
./utils/init/miscinit.c
./utils/misc/superuser.c
./utils/sort/tuplesort.c
./utils/sort/tuplestore.c
./utils/time/combocid.c
./utils/time/tqual.c

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services