Thread: Include files for SPI are not installed
Certain include files are installed by src/include/Makefile and by interfaces/libpq++/Makefile. However, they in turn include others that are not installed, thus obviating the usefulness of the ones that are. The missing files are these: access/heapam.h access/htup.h access/relscan.h access/rmgr.h access/sdir.h access/skey.h access/strat.h access/transam.h access/tupdesc.h access/tupmacs.h access/xact.h access/xlogdefs.h access/xlog.h access/xlogutils.h catalog/pg_am.h catalog/pg_attribute.h catalog/pg_class.h catalog/pg_language.h catalog/pg_proc.h catalog/pg_type.h executor/execdefs.h executor/execdesc.h executor/executor.h executor/hashjoin.h executor/tuptable.h nodes/execnodes.h nodes/memnodes.h nodes/nodes.h nodes/params.h nodes/parsenodes.h nodes/pg_list.h nodes/plannodes.h nodes/primnodes.h nodes/relation.h pgconnection.h pgdatabase.h pgtransdb.h rewrite/prs2lock.h storage/block.h storage/buffile.h storage/buf.h storage/bufmgr.h storage/bufpage.h storage/fd.h storage/ipc.h storage/item.h storage/itemid.h storage/itemptr.h storage/lmgr.h storage/lock.h storage/off.h storage/page.h storage/relfilenode.h storage/shmem.h storage/spin.h tcop/dest.h tcop/pquery.h tcop/tcopprot.h tcop/utility.h utils/builtins.h utils/datetime.h utils/datum.h utils/fcache.h utils/hsearch.h utils/memutils.h utils/nabstime.h utils/numeric.h utils/portal.h utils/rel.h utils/syscache.h utils/timestamp.h utils/tqual.h The list can be regenerated with the attached script. Example: $ pg_includes /usr/local/pgsql/include Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "He hath not dealt with us after our sins; nor rewarded us according to ouriniquities. For as the heaven is high above the earth, so great is his mercy toward them that fear him. As faras the east is from the west, so far hath he removed our transgressions from us." Psalms 103:10-12
On Tue, 6 Feb 2001, Oliver Elphick wrote:
> Certain include files are installed by src/include/Makefile and by
> interfaces/libpq++/Makefile. However, they in turn include others that
> are not installed, thus obviating the usefulness of the ones that are.
In your module you can use arbitrary routines from PG not only SPI,
for example you trigger needs work with some datetypes and for this
needs include anything from include/utils/ ... It expect install *all*
header files. Not is better download PG sources and use -I option for
your gcc?
I expect header files on /usr/include/pgsql for client programming not
for SPI.
Karel
Oliver Elphick wrote: > Certain include files are installed by src/include/Makefile and by > interfaces/libpq++/Makefile. However, they in turn include others that > are not installed, thus obviating the usefulness of the ones that are. > The missing files are these: [snip] > The list can be regenerated with the attached script. Or use this one-liner (CWD=the include directory in the source dist): /lib/cpp -M -I. -I../backend executor/spi.h | \xargs -n 1| \grep \\W| \grep -v ^/| \grep -v spi.o | \grep -v spi.h | \sort (There are better ways of doing the regexps, I know). I use this in the RPM spec file to pull over the SPI headers, and have had to do so since 6.5.x days. Bruce, can we add a TODO item for make install to install _all_ necessary headers, including SPI ones? It is not at all necessary to have a source tree lying around to do SPI development (or at least it _shouldn't_ be necessary). A full source tree, configured and built, according to du, takes about 48MB of space (a pristine tree takes 36MB or so in comparison). The complete set of headers takes a little less than 1MB of space. (1MB of _headers_? Yow!) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Karel Zak wrote: > On Tue, 6 Feb 2001, Oliver Elphick wrote: > > Certain include files are installed by src/include/Makefile and by > > interfaces/libpq++/Makefile. However, they in turn include others that > > are not installed, thus obviating the usefulness of the ones that are. > In your module you can use arbitrary routines from PG not only SPI, > for example you trigger needs work with some datetypes and for this > needs include anything from include/utils/ ... It expect install *all* > header files. Not is better download PG sources and use -I option for > your gcc? No. Full tree takes at minimum 36MB -- even pulling the _entire_ src/include tree over is only 2MB. > I expect header files on /usr/include/pgsql for client programming not > for SPI. Why? I know of several people doing SPI work with no source tree installed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Tue, 6 Feb 2001, Lamar Owen wrote:
> Karel Zak wrote:
> > On Tue, 6 Feb 2001, Oliver Elphick wrote:
> > > Certain include files are installed by src/include/Makefile and by
> > > interfaces/libpq++/Makefile. However, they in turn include others that
> > > are not installed, thus obviating the usefulness of the ones that are.
>
> > In your module you can use arbitrary routines from PG not only SPI,
> > for example you trigger needs work with some datetypes and for this
> > needs include anything from include/utils/ ... It expect install *all*
> > header files. Not is better download PG sources and use -I option for
> > your gcc?
>
> No. Full tree takes at minimum 36MB -- even pulling the _entire_
> src/include tree over is only 2MB.
Agree, *all* in src/include is good idea, but current /usr/include is
away from this. Oliver's idea was include needful SPI stuff only.
Before 1.5 years I wrote first trigger for PG and first thing I found
that /usr/include is not usable for me.
> > I expect header files on /usr/include/pgsql for client programming not
> > for SPI.
>
> Why? I know of several people doing SPI work with no source tree
> installed.
Hmm, it must be very limited outlook without source tree:-)
Karel
Lamar Owen <lamar.owen@wgcr.org> writes:
> Karel Zak wrote:
>> I expect header files on /usr/include/pgsql for client programming not
>> for SPI.
> Why? I know of several people doing SPI work with no source tree
> installed.
I agree with Karel on this --- it's difficult to visualize doing useful
SPI work without a source tree at hand, and it also seems unlikely that
SPI authors would get along for long with *only* those header files
needed to pull in spi.h. So I think it's pretty pointless to add just
those header files.
What would make more sense is for the standard install to install only
those headers needed for *client side* programming, and then to have
an optional install target that installs the whole darn src/include
tree. (Or in RPM terms, a client-devel RPM and a separate server-devel
RPM that adds the rest of src/include.) Anything in between is
guaranteed to be the wrong set of files.
regards, tom lane
Tom Lane wrote: > I agree with Karel on this --- it's difficult to visualize doing useful > SPI work without a source tree at hand, and it also seems unlikely that > SPI authors would get along for long with *only* those header files > needed to pull in spi.h. So I think it's pretty pointless to add just > those header files. I'm waiting to see what Mike Mascari says about the issue, as he is doing SPI work from an RPM install (no source) and was the gadfly (in the best sense of the word) that got me putting the SPI headers in in the first place. Besides headers, what files are required? Makefile.global? Makefile.shlib? ??? > What would make more sense is for the standard install to install only > those headers needed for *client side* programming, and then to have > an optional install target that installs the whole darn src/include > tree. I can go for that. > (Or in RPM terms, a client-devel RPM and a separate server-devel > RPM that adds the rest of src/include.) Anything in between is > guaranteed to be the wrong set of files. Ok, RPM users who do SPI work, sound off. Which would you like? I'll admit to liking the idea Tom has put forward, but I want more feedback. I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to throw out a tentative name. I am loath to split the existing -devel subpackage into two packages with different names, throwing out the original, but I can do that as well, if that is the consensus. The contents of -devel would be the headers installed by 'make install' -- although I question why spi.h and some friends are installed in the first place, given the 'client-side' focus (but this _is_ what Tom just said -- I'm just being a little more specific). The contents of -devel-spi (or maybe just -spi) would be all the other headers (no duplicates) (again, expounding upon what Tom said already). Comments? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> I agree with Karel on this --- it's difficult to visualize doing useful > SPI work without a source tree at hand, and it also seems unlikely that > SPI authors would get along for long with *only* those header files > needed to pull in spi.h. So I think it's pretty pointless to add just > those header files. > > What would make more sense is for the standard install to install only > those headers needed for *client side* programming, and then to have > an optional install target that installs the whole darn src/include > tree. (Or in RPM terms, a client-devel RPM and a separate server-devel > RPM that adds the rest of src/include.) Anything in between is > guaranteed to be the wrong set of files. Agreed. I hesitate to copy all those *.h files when few people use them. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Lamar Owen <lamar.owen@wgcr.org> writes:
> Tom Lane wrote:
>> What would make more sense is for the standard install to install only
>> those headers needed for *client side* programming, and then to have
>> an optional install target that installs the whole darn src/include
>> tree.
> I can go for that.
>> (Or in RPM terms, a client-devel RPM and a separate server-devel
>> RPM that adds the rest of src/include.) Anything in between is
>> guaranteed to be the wrong set of files.
> Ok, RPM users who do SPI work, sound off. Which would you like? I'll
> admit to liking the idea Tom has put forward, but I want more feedback.
> I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to
> throw out a tentative name. I am loath to split the existing -devel
> subpackage into two packages with different names, throwing out the
> original, but I can do that as well, if that is the consensus.
client-devel and server-devel are the right division IMHO. SPI is a
subset of server-side development, but not all server-side code needs
SPI. Consider user-written functions and datatypes. These guys do not
need SPI (usually), but they do need access to header files that aren't
installed now.
> The contents of -devel would be the headers installed by 'make install'
> -- although I question why spi.h and some friends are installed in the
> first place, given the 'client-side' focus (but this _is_ what Tom just
> said -- I'm just being a little more specific).
My thought was that we'd remove spi.h from the minimal install, along
with anything else that's not useful for client-side programming. Thus
the standard install footprint would get smaller. I haven't looked to
see exactly what the list of client-side headers should be, but if
people like this idea I will do the legwork to make the list.
regards, tom lane
Tom Lane wrote: > client-devel and server-devel are the right division IMHO. SPI is a > subset of server-side development, but not all server-side code needs > SPI. Consider user-written functions and datatypes. These guys do not Ok, I can do that. Obsoletes:devel here we come! > My thought was that we'd remove spi.h from the minimal install, along > with anything else that's not useful for client-side programming. Thus > the standard install footprint would get smaller. I haven't looked to > see exactly what the list of client-side headers should be, but if > people like this idea I will do the legwork to make the list. Count me as liking it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11