Thread: Server Side C programming Environment Set up
I read a lot of document and did some search and looked at the source code of postgres but did not find a simple solution to my question. How to set up the programming environment for C. IN chapter 33 Extending SQL 33.7.5 Writing Code when run pg_config --includedir-server I got /usr/local/pgsql/include/server but my machine does have this directory I looked at configure --help, no mentioning about how to install server side include and lib files. I do see postgres.h src/include/executor/spi.h /src/include/commands/trigger.h located in the source distribution. Is there a simple configure flag or some program (shell script) in the source distribution to set up the programming environment? Kemin ********************************************************************** Proprietary or confidential information belonging to Ferring Holding SA or to one of its affiliated companies may be containedin the message. If you are not the addressee indicated in this message (or responsible for the delivery of the messageto such person), please do not copy or deliver this message to anyone. In such case, please destroy this message andnotify the sender by reply e-mail. Please advise the sender immediately if you or your employer do not consent to e-mailfor messages of this kind. Opinions, conclusions and other information in this message represent the opinion of thesender and do not necessarily represent or reflect the views and opinions of Ferring. **********************************************************************
Kemin Zhou wrote: > IN chapter 33 Extending SQL > 33.7.5 Writing Code > when run pg_config --includedir-server > I got /usr/local/pgsql/include/server but my machine does have this > directory make install-all-headers It's explained in the installation instructions.
Peter Eisentraut <peter_e@gmx.net> writes: > make install-all-headers That's not a complete solution though; the headers are only half the problem. Makefiles are the other half, and our story on them is pretty bad. For instance I've been meaning to ask what to do about this open bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244 If you don't have working Makefiles, it doesn't help that much to have all the headers. I think Lamar's perennial issues with running the regression tests in an RPM installation are closely related too ... regards, tom lane
On Thu, 2004-04-22 at 01:18, Peter Eisentraut wrote: > Kemin Zhou wrote: > > IN chapter 33 Extending SQL > > 33.7.5 Writing Code > > when run pg_config --includedir-server > > I got /usr/local/pgsql/include/server but my machine does have this > > directory > > make install-all-headers > > It's explained in the installation instructions. That doesn't happen on most platforms in the standard package. Are you proposing that packagers create a postgresql-headers package and depend on that? If this is the suggested way of solving the headers portion of the problem then lets tell the packagers.
Peter Eisentraut <peter_e@gmx.net> writes: > Am Donnerstag, 22. April 2004 07:59 schrieb Tom Lane: >> For instance I've been meaning to ask what to do about this open >> bug report: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244 > Well, perhaps getting the tutorial to compile should be part of the tutorial > itself. :) But that doesn't have anything to do with server side C > programming. You don't need any PostgreSQL makefiles for that. Hm? src/tutorial contains two .c files that need to be compiled. The bug report is that the Makefile provided for this only works in the original build tree. regards, tom lane
Rod Taylor <pg@rbt.ca> writes:
> On Thu, 2004-04-22 at 01:18, Peter Eisentraut wrote:
>> make install-all-headers
>>
>> It's explained in the installation instructions.
> That doesn't happen on most platforms in the standard package.
Depends what you mean by "standard package"? The PGDG and Red Hat RPMs
certainly do install-all-headers. They are in the postgresql-devel
package, which seems appropriate to me.
I agree with the suggestion elsewhere in the thread about generalizing
the contrib Makefile framework to the point that it could be installed
as part of the -devel RPM, and then used to build user-written backend
functions. Ideally you could take one of the contrib subdirectories
by itself, and build it using only what is installed by postgresql-devel,
without needing access to the original source or build trees. I don't
think we are real close yet, though maybe Peter would have an idea what
would be needed. (Note this would also provide a usable solution to the
build-the-tutorial problem I mentioned.)
regards, tom lane
On Thu, 2004-04-22 at 10:11, Peter Eisentraut wrote: > Am Donnerstag, 22. April 2004 15:58 schrieb Rod Taylor: > > > make install-all-headers > > > > > > It's explained in the installation instructions. > > > > That doesn't happen on most platforms in the standard package. > > It certainly happens in all the packages that have ever come by me (maybe > after a little complaining). Okay, I'll start submitting patches for the packages we tend to use here.
Am Donnerstag, 22. April 2004 15:58 schrieb Rod Taylor: > > make install-all-headers > > > > It's explained in the installation instructions. > > That doesn't happen on most platforms in the standard package. It certainly happens in all the packages that have ever come by me (maybe after a little complaining).
Am Donnerstag, 22. April 2004 07:59 schrieb Tom Lane: > Peter Eisentraut <peter_e@gmx.net> writes: > > make install-all-headers > > That's not a complete solution though; the headers are only half the > problem. Makefiles are the other half, and our story on them is pretty > bad. For instance I've been meaning to ask what to do about this open > bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244 Well, perhaps getting the tutorial to compile should be part of the tutorial itself. :) But that doesn't have anything to do with server side C programming. You don't need any PostgreSQL makefiles for that.
Rod Taylor wrote: >On Thu, 2004-04-22 at 01:18, Peter Eisentraut wrote: > > >>Kemin Zhou wrote: >> >> >>>IN chapter 33 Extending SQL >>>33.7.5 Writing Code >>>when run pg_config --includedir-server >>>I got /usr/local/pgsql/include/server but my machine does NOT have this >>>directory >>> >>> >>make install-all-headers >> >>It's explained in the installation instructions. >> >> > >That doesn't happen on most platforms in the standard package. > >Are you proposing that packagers create a postgresql-headers package and >depend on that? > >If this is the suggested way of solving the headers portion of the >problem then lets tell the packagers. > > > > As fas I am concerned, being a generalized programer, to program the serverside functionality I would need a header file that should include nearly all the server side functionality and a lib, presumably dynamically linkable lib file libpgserver.so. We already have the interface library libpq.so The server side header does not have to include everything. It only needs to be the parts that the user programer needs to manipulate (SPI?). I see a great advantage to be able to plug in some information_managing algorithms into Postgres. Kemin ********************************************************************** Proprietary or confidential information belonging to Ferring Holding SA or to one of its affiliated companies may be containedin the message. If you are not the addressee indicated in this message (or responsible for the delivery of the messageto such person), please do not copy or deliver this message to anyone. In such case, please destroy this message andnotify the sender by reply e-mail. Please advise the sender immediately if you or your employer do not consent to e-mailfor messages of this kind. Opinions, conclusions and other information in this message represent the opinion of thesender and do not necessarily represent or reflect the views and opinions of Ferring. **********************************************************************
Am Donnerstag, 22. April 2004 18:07 schrieb Tom Lane: > I agree with the suggestion elsewhere in the thread about generalizing > the contrib Makefile framework to the point that it could be installed > as part of the -devel RPM, and then used to build user-written backend > functions. It seems to me that you are proposing to recreate the same sort of framework that we have fought for years to get rid of in the cases of Perl, Python, and others. Some reasons for why this is not a good idea are: It would restrict users of that framework to use the same compiler that was used to build PostgreSQL. History shows that this assumptions fails surprisingly often. When someone wants to build a glue module between PostgreSQL and some other largish package (say, Perl, although that one exists already), then whose framework do you use? Sometimes building outside of these frameworks becomes extremely difficult. Without a configuration routine of its own, add-on packages are restricted to using the information that the main PostgreSQL configuration already provides. If someone needs to detect or evaluate additional libraries there is no chance. I'd be happy to write more documentation, howtos, or scripts and tools that enable users to set up a proper build system, but I don't think it's our business to try to write our own build system framework.
Peter Eisentraut <peter_e@gmx.net> writes:
> I'd be happy to write more documentation, howtos, or scripts and tools that
> enable users to set up a proper build system, but I don't think it's our
> business to try to write our own build system framework.
Any build framework is going to have limitations, obviously, and it
would be bad to design things to prevent subprojects from having their
own. But I think that is no argument for not having a build framework
at all. If we try to go that route, we'll be killing a lot of useful
code that isn't quite valuable enough (in isolation) for people to
expend the work to create their own build system for.
Even more to the point, we've already *got* a build framework, which by
demonstration works for many of the bits of code that we are talking
about spinning off. What we have to do is adjust it so it still works
for them after they're spun off. It seems silly to abandon the
not-trivial work you and other people have already put into the contrib
build system; and also silly to expect gborg projects to individually
adapt it to their needs.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I'd be happy to write more documentation, howtos, or scripts and tools that > > enable users to set up a proper build system, but I don't think it's our > > business to try to write our own build system framework. > > Any build framework is going to have limitations, obviously, and it > would be bad to design things to prevent subprojects from having their > own. But I think that is no argument for not having a build framework > at all. If we try to go that route, we'll be killing a lot of useful > code that isn't quite valuable enough (in isolation) for people to > expend the work to create their own build system for. > > Even more to the point, we've already *got* a build framework, which by > demonstration works for many of the bits of code that we are talking > about spinning off. What we have to do is adjust it so it still works > for them after they're spun off. It seems silly to abandon the > not-trivial work you and other people have already put into the contrib > build system; and also silly to expect gborg projects to individually > adapt it to their needs. Bingo! We have often had the attitude "If we can't do it perfectly, don't do it". While that applies is some cases, it doesn't apply everywhere, and we need to be wise in determining when we are helping people by giving them a 99% solution. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073