Thread: SPI & file locations
I'm afraid this might sound rather dumb. I'm hoping I can just get a little clarification about file locations. I've just started playing w/ SPI. As a first stab, I thought I'd compile a couple of the test applications in /contrib. I pointed gcc to include files from /usr/local/pgsql - i.e. 'gcc ... -I/usr/local/pgsql/include ...'. This of course didn't work. /usr/local/pgsql/include/executor/spi.h attempts to include files which don't exist in the install directory. They only exist in /usr/local/src/postgresql-7.0/src/include (or wherever you put the source). After installation, shouldn't everything you need be in /usr/local/pgsql? It's simple enough to just use /usr/local/src/postgresql-7.0/src/include. But I don't know when to use one, and when to use the other. Sorry if this is a completely naive question. I'm pretty much flying solo here. I'm an architect who's gotten frustrated with the scaleability limitations of using something like MS Access. I'm the only person I know who uses any *NIX whatsoever, nevermind PostgreSQL. C/C++ doesn't bother me, but I'm really not too familiar w/ *NIX file conventions, etc. -Ron-
Ron Peterson <rpeterson@yellowbank.com> writes:
> After installation, shouldn't everything you need be in
> /usr/local/pgsql?
Yeah, it should really. We've had this discussion before. The real
problem is that no one wants to install the entire pgsql include tree,
but it's hard to draw the line at what an SPI extension might need or
not need. It doesn't help that we've been sloppy about what lives in
which include file, too :-(. Sooner or later someone should go through
the whole include tree and try to rearrange things so that there's a
fairly compact set of files that need to be exported.
In the meantime, pointing at the source tree is a good way to build SPI
extensions...
regards, tom lane
Ron Peterson wrote: > > I'm afraid this might sound rather dumb. I'm hoping I can just get a > little clarification about file locations. > > I've just started playing w/ SPI. As a first stab, I thought I'd > compile a couple of the test applications in /contrib. > > I pointed gcc to include files from /usr/local/pgsql - i.e. 'gcc ... > -I/usr/local/pgsql/include ...'. This of course didn't work. > /usr/local/pgsql/include/executor/spi.h attempts to include files which > don't exist in the install directory. They only exist in > /usr/local/src/postgresql-7.0/src/include (or wherever you put the > source). > > After installation, shouldn't everything you need be in > /usr/local/pgsql? I too have run into this dependency problem. The number of headers required to compile an SPI code module is around 80, if I recall correctly. Lamar Owen was good enough to include those headers as apart of the RPM distribution and they would go into /usr/include/pgsql. I believe he got the dependency list from Oliver Elphick who manages the Debian package, so that should be correct as well. If you're not using RedHat or Debian distrubitions, I think you're stuck with keeping the backend source tree lying around. :-( Mike Mascari
So I got the moddatetime trigger example in /contrib working. A couple of notes: moddatetime.c makes reference to DATETIME. This needs to be changed to TIMESTAMP. I've done this, if you want the source. I need to make .so files in two steps: first make a regular object file, then compile that w/ -fpic and -shared and output an .so file. If I try to do this in one step, it doesn't work. This may very well be the way the compiler is _supposed_ to work, I dunno. RH6.1, kernel 2.2.13, gcc version egcs-2.91.66_19990314/Linux (egcs-1.1.2 release). -Ron-
On Fri, 26 May 2000, Mike Mascari wrote: > Ron Peterson wrote: > > After installation, shouldn't everything you need be in > > /usr/local/pgsql? Too many assumptions are in the source that the source will always be there. Not necessarily true! > I too have run into this dependency problem. The number of > headers required to compile an SPI code module is around 80, if I > recall correctly. Lamar Owen was good enough to include those > headers as apart of the RPM distribution and they would go into > /usr/include/pgsql. I believe he got the dependency list from > Oliver Elphick who manages the Debian package, so that should be For PostgreSQL 7.0-2 and above, the SPI header list is dynamically generated during package build and manually copied into place using the following one-liner: /lib/cpp -M -I. -I../backend executor/spi.h |xargs -n 1|grep \\W|grep -v ^/|grep -v spi.h | sort |cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql Replace $RPM_BUILD_ROOT/usr/include/pgsql with the directory of your choice, and run this one-liner when the cwd is in src/include in the PostgreSQL source tree. The sort is optional, of course. This could easily enough be included in the make install, couldn't it? (Tom? Anyone?) I realize that GNU grepisms (or is \W common?) are used above, but, after all, I _know_ my one-liner in the RPM spec file installation section is going to be running on RedHat with a complete development environment, so it wasn't designed to be portable. I also realize the regexps could be tuned to only need a single grep invocation, but, it works and works nicely as-is in the RPM building environment. Oh, BTW, there's the same number of header includes as there were with 6.5.3, but there are differences in the list.... SPI development CAN be done without 26+ MB of source code taking up space -- Mike is _doing_ it, IIRC. In fact, Mike is the one who prodded me to get it working in the RPMs. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Fri, 26 May 2000, Tom Lane wrote: > Ron Peterson <rpeterson@yellowbank.com> writes: > > After installation, shouldn't everything you need be in > > /usr/local/pgsql? > Yeah, it should really. We've had this discussion before. The real > problem is that no one wants to install the entire pgsql include tree, > but it's hard to draw the line at what an SPI extension might need or If it only needs what spi.h depends upon, then the line is drawn by the one-liner in my other message. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> /lib/cpp -M -I. -I../backend executor/spi.h |xargs -n 1|grep \\W|grep -v ^/|grep -v spi.h | sort |cpio -pdu
$RPM_BUILD_ROOT/usr/include/pgsql
> This could easily enough be included in the make install, couldn't it?
> (Tom? Anyone?) I realize that GNU grepisms (or is \W common?) are
> used above,
That's just the tip of the iceberg of the portability problems in the
above. If you want to propose that we actually do something like that
during 'make install', you're gonna have to work a lot harder.
(However, as a non-portable trick for getting a list of files that need
to be included in a hand-generated makefile, it's not bad.)
The more serious problem is "what else might an SPI module need besides
spi.h". Also, it disturbs me a lot that spi.h pulls in 80+ include
files in the first place --- there's got to be stuff in there that
needn't/shouldn't be exported. I know that an SPI developer who's just
trying to get some work done couldn't care less, but I'd like to see us
make some effort to actually clean up the list of files to be exported,
rather than fall back on automation that will let the list bloat even
more without anyone much noticing...
regards, tom lane