Обсуждение: development setup and libdir
I finally put enough code together and it has some chance it could work. It's time to test it. Now I'm going to test it quite frequently. My code is written and compiled in my ~/. Then it is moved through svn to a test box where it is compiled under another version of postgres, but still it ends up "far away" from anything pg related. Now it would be nice to be able to test it without any modification to the source (namely the sql.in file). But the kosher way to write one and then be able to eventually package it into a deb or even make it reach contrib would be to use $libdir. I can't make install (provided it works as expected, I didn't try yet) since I sincerely hope that my user doesn't have write right on whatever is pointed by $libdir. My *nix user is also postgres superuser. One way would be to - let postgres user (or anyone) read in the dev dir - export USE_PGXS=1; export someunknownparam=`pwd`; make So that the resulting module.sql will point to the dev dir. Does that someunknownparam exist? 2nd choice would be to write a bash script that just - make - sed -e 's/\$libdir/'`pwd`'/g' module.sql > module.l.sql - sed -e 's/\$libdir/'`pwd`'/g' uninstall_module.sql > uninstall_module.l.sql - psql < sometestcode.sql Not that bad... but if that "someunknownparam" existed it would be nicer and avoid hard coding the module name in 2 places (Makefile and bash script)[1] [1] OK I know I can parse the Makefile with sed... ;) thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> ... I can't make install (provided it works as expected, I didn't try
> yet) since I sincerely hope that my user doesn't have write right on
> whatever is pointed by $libdir.
Why not? In order to install a C function, you have to be superuser,
which means you already have the keys to the kingdom database-wise.
There is no reason to not give a developer of C functions write access
on $libdir. He could do whatever he wanted inside the C code anyway.
regards, tom lane
On Sat, 30 Jan 2010 11:06:02 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Ivan Sergio Borgonovo <mail@webthatworks.it> writes: > > ... I can't make install (provided it works as expected, I > > didn't try yet) since I sincerely hope that my user doesn't have > > write right on whatever is pointed by $libdir. > > Why not? In order to install a C function, you have to be > superuser, which means you already have the keys to the kingdom > database-wise. There is no reason to not give a developer of C > functions write access on $libdir. He could do whatever he wanted > inside the C code anyway. It's not just about security, it's about maintenance. Anyway I may have more than one instance of pg running but all will point to the same lib directory and anyway if I'm going to use distribution package I don't want things that mix (and may be overwritten). Still I should give write access to myself as a "developer" to a system directory I really shouldn't have access too (and on Debian it should be root:root if I'm remembering right). Anyway I'm just getting acquainted with pg build system and today I just learnt a lot on #postgresql. Again... as soon as I'll have something working, I'll post what I've learnt from the experience somewhere. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Sat, 30 Jan 2010 11:06:02 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Ivan Sergio Borgonovo <mail@webthatworks.it> writes: > > ... I can't make install (provided it works as expected, I > > didn't try yet) since I sincerely hope that my user doesn't have > > write right on whatever is pointed by $libdir. > > Why not? In order to install a C function, you have to be > superuser, which means you already have the keys to the kingdom > database-wise. There is no reason to not give a developer of C > functions write access on $libdir. He could do whatever he wanted > inside the C code anyway. It is becoming a more serious issue than what I thought... Debian install everything in /usr/lib/postgresql/8.3/lib/ -rw-r--r-- 1 root root so definitively it would be hard to write there. Still I'd like to keep a standard installation of Debian and just compile my extension somewhere else where the postgres user can read. I just discovered that depending on the postgres version .so are created with different names (module.so vs libmodule.so) and then renamed. Since I'd like to use as much as possible of all the magic that pgxs and provided makefile do... and I may discover that the renaming is not the only change between versions, I'd prefer all this magic happens using make install. I've read I can use prefix. From my understanding you can set prefix from configure but: - maybe you've just installed debian -dev package - running configure for each extension you'd like to place in a different path is just a pain especially if you would reallylike to keep configuration identical with the exception of the install dir I've tried to export USE_PGSX=1; make install /mydir export USE_PGSX=1; make install prefix=/mydir with no success. make still try to copy stuff in /usr/lib/postgresql/... What am I supposed to do to install modules where I want? thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote: > On Sat, 30 Jan 2010 11:06:02 -0500 > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> Ivan Sergio Borgonovo <mail@webthatworks.it> writes: >> >>> ... I can't make install (provided it works as expected, I >>> didn't try yet) since I sincerely hope that my user doesn't have >>> write right on whatever is pointed by $libdir. >>> >> Why not? In order to install a C function, you have to be >> superuser, which means you already have the keys to the kingdom >> database-wise. There is no reason to not give a developer of C >> functions write access on $libdir. He could do whatever he wanted >> inside the C code anyway. >> > > It is becoming a more serious issue than what I thought... > Debian install everything in > /usr/lib/postgresql/8.3/lib/ > -rw-r--r-- 1 root root > so definitively it would be hard to write there. > > Still I'd like to keep a standard installation of Debian and just > compile my extension somewhere else where the postgres user can read. > > I just discovered that depending on the postgres version .so are > created with different names (module.so vs libmodule.so) and then > renamed. Since I'd like to use as much as possible of all the magic > that pgxs and provided makefile do... and I may discover that the > renaming is not the only change between versions, I'd prefer all > this magic happens using make install. > > I've read I can use prefix. > From my understanding you can set prefix from configure but: > - maybe you've just installed debian -dev package > - running configure for each extension you'd like to place in a > different path is just a pain especially if you would really like > to keep configuration identical with the exception of the install > dir > > I've tried to > export USE_PGSX=1; make install /mydir > export USE_PGSX=1; make install prefix=/mydir > with no success. make still try to copy stuff > in /usr/lib/postgresql/... > > What am I supposed to do to install modules where I want? > > > pgxs is about building somrthing that will install in the configured locations. If you don't want to install in the configured locations don't build/install with pgxs. For development purposes you would be far better off building a private version of postgres (with configure --prefix=/path) and using its pgxs to build, install and test your module. cheers andrew
On Sat, 30 Jan 2010 16:51:44 -0500 Andrew Dunstan <andrew@dunslane.net> wrote: > Ivan Sergio Borgonovo wrote: > > It is becoming a more serious issue than what I thought... > > Debian install everything in > > /usr/lib/postgresql/8.3/lib/ > > -rw-r--r-- 1 root root > > so definitively it would be hard to write there. > > > > Still I'd like to keep a standard installation of Debian and just > > compile my extension somewhere else where the postgres user can > > read. [snip] > > What am I supposed to do to install modules where I want? > pgxs is about building somrthing that will install in the > configured locations. If you don't want to install in the > configured locations don't build/install with pgxs. > For development purposes you would be far better off building a > private version of postgres (with configure --prefix=/path) and > using its pgxs to build, install and test your module. That's pretty expensive. I mean... I just would like my .so end up with the expected name somewhere else. I can put up a working postgres installation just using aptitude and having a semi-functional[1] dev environment installing postgres -dev package. Requiring I compile a private version of postgres[1] increase the cost of development unreasonably, considering that what's missing is being able to provide install dir as a parameter during make install I'm absolutely aware I can't ask features unless someone is willing to implement them or is paid for... but the easier/cheaper it is to build up a dev/test environment the more people will try to build/test something for postgres. Of course I can write a script that can workaround this. It seems that the only thing missing is that pgxs 8.3 used to prefix .so with lib and then rename them at install time, but pgxs 8.4 build them directly without prefix. I'm just speculating this is the issue and it is the only one I still have to solve... but... what's going to happen next release? Wouldn't it be better if make install could install stuff where I ask so I could put modules in different places *even* for the same installation of postgres? I'll write my script. I can do my homework and I'm not expecting someone else make using pgxs nicer but still it doesn't look an unreasonable feature. I mean... what's so weird about being able to develop postgres modules without requiring people build the whole postgresql or switching back and forward from root? And... it's really a pity... I mean... I'm so near to build and test modules just doing aptitude install postgresql postgresql-server-dev-8.4 [1] that's not just compile, you've to set it up, make it start at boot, make it work on a different port... There is already a lot of work made by distribution packagers. Why should it be wasted? [2] semi-functional... because I can't actually install modules with the provided tools where I'd like to have them. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote: > I'm absolutely aware I can't ask features unless someone is willing > to implement them or is paid for... but the easier/cheaper it is to > build up a dev/test environment the more people will try to > build/test something for postgres. > I do all my build/test work on Ubuntu using my peg tool: http://github.com/gregs1104/peg specifically because I find it such a giant pain to deal with the Debian packaging when developing. It does all of the things you're complaining take too long to setup just for development work. Dump the whole working tree in your home directory, build and test everything there, avoid the whole mess of what the OS install cares about. Once I've got something that works, only then do I bother figuring out how I'm going to get that integrated back into the packaging system's PostgreSQL install. The difficulties in making modules generally easier to install are well understood, and many people have been working on potential improvements to that whole situation for a while now. It's a hard problem though. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Sat, Jan 30, 2010 at 5:36 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote: >> For development purposes you would be far better off building a >> private version of postgres (with configure --prefix=/path) and >> using its pgxs to build, install and test your module. > > That's pretty expensive. How? I rebuild the backend five or ten times a day when doing PG work. Doesn't seem like a big deal. ...Robert
On Jan 30, 2010, at 3:36 PM, Ivan Sergio Borgonovo wrote: >> For development purposes you would be far better off building a >> private version of postgres (with configure --prefix=/path) and >> using its pgxs to build, install and test your module. > > That's pretty expensive. eh: jwp@torch[]:org/postgresql/git 0% ls /src/build pg pg-nodb-plpy pg81 pg83 pg85 pg_foreach py py31-nodb pg-nodb pg80 pg82 pg84 pg90 pgweb py31 The tricky part is that they tend to multiply. ;) > Requiring I compile a private version of postgres[1] > increase the cost of development unreasonably, That install of PG that you're using will *probably not* have debugging information. Now, granted, you might not need PG with debugging for some problems, but chances are that you'll come across one (or twoor fifty or so) where you *will* need it. I'd suggest using a private install for dev as well. Enable debugging and casserts, and make sure your ulimit's allow coredumps. I'm not sure if pgxs can do what you want or not, but using a private prefix works well enough for me.
Ivan Sergio Borgonovo escreveu: > That's pretty expensive. > Ugh? > I mean... I just would like my .so end up with the expected name > somewhere else. It's just two command lines [1]. > Wouldn't it be better if make install could install stuff where I > ask so I could put modules in different places *even* for the same > installation of postgres? Why do you want to mess your installation? Besides, you will need to add the install path in dynamic_library_path and or the absolute path to your CREATE FUNCTION script. Man, that's too much work for a packager! Of course, you can always build on your way; that's up to you. > I mean... what's so weird about being able to develop postgres > modules without requiring people build the whole postgresql or > switching back and forward from root? > Ugh? You don't need root; I mean, you can always set absolute path or even the dynamic_library_path [2] parameter. [1] http://www.postgresql.org/docs/8.4/static/xfunc-c.html#DFUNC [2] http://www.postgresql.org/docs/8.4/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-OTHER -- Euler Taveira de Oliveira http://www.timbira.com/
On Sat, 30 Jan 2010 18:32:58 -0500 Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Jan 30, 2010 at 5:36 PM, Ivan Sergio Borgonovo > <mail@webthatworks.it> wrote: > >> For development purposes you would be far better off building a > >> private version of postgres (with configure --prefix=/path) and > >> using its pgxs to build, install and test your module. > > That's pretty expensive. > How? I rebuild the backend five or ten times a day when doing PG > work. Doesn't seem like a big deal. I'm not scared about compile time. But considering that what it's really missing between what I need and what I get is renaming a file... it's just a pain I've to set up a whole new instance of postgres, install the whole source etc... I think most of you are core developers or people that really invest and have invested a reasonably large % of your time in postgres development. It makes sense to have a complete development environment[1]. But well again... considering I'm a "rename" away from being able to compile and test an extension with my user privileges... it's just a pity it doesn't work that way out of the box. Another scenario could be I could just svn update on a staging box, compile there and then move everything to production easier. Not every shop is a multimillion dollars enterprise that can afford a dev/staging/production box for every version of postgres it is using. If you don't need to squeeze out every cpu cycle in a production box you may be happy with a pre-packaged postgres. I admit my approach may be naïve considering the build system has to work on many architecture/OSes... so the problems that have to be solved just to install somewhere else may be more complicated but still I think my need isn't that weird and could lower the entry point for many developers quite a bit. I've spent some time greping through makefile to see if I could propose a patch. From my point of view passing a parameter at make install time would make things much better. Another thing I had to tweak was the path in in.sql (that one should be taken from a parameter too). Ideally once you write the source code... where/how you're going to use it should just depend on parameters passed at make time. Now my main concern is making my C code work in a reasonably decent development environment. I hope if I'll ever succeed to take this project to an end before being forced to take care of other stuff, my code or my documented experience will come useful to others. Trying to understand how pgxs works may be my next effort, right now I'll use a workaround since just being able to build and load my modules wherever I want is going to make *my* development experience much manageable. I still think that *my* need is not that weird. Now let's see if I can come up with a useful module. At least one other user of postgres has shown interest on what I was trying to do on pgsql-general. Next step in my postgres awareness may be using peg. Thanks Greg. [1] and yeah I'll need dbg symbols but that's going to happen later. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote: > > Now my main concern is making my C code work in a reasonably decent > development environment. I hope if I'll ever succeed to take this > project to an end before being forced to take care of other stuff, > my code or my documented experience will come useful to others. > Trying to understand how pgxs works may be my next effort, right now > I'll use a workaround since just being able to build and load my > modules wherever I want is going to make *my* development experience > much manageable. > > I still think that *my* need is not that weird. > > Now let's see if I can come up with a useful module. At least one > other user of postgres has shown interest on what I was trying to do > on pgsql-general. > > Next step in my postgres awareness may be using peg. Thanks Greg. > > [1] and yeah I'll need dbg symbols but that's going to happen later. > > The trouble is that you keep thinking pgxs is there to help you with development, and wanting it to do things it was never designed for. But it's really there to help with packaging and distribution, IMNSHO. If you are developing a postgres module, suggesting that you configure and install postgres for use with that development is not unreasonable, despite your assertion to the contrary. If I am developing, say, a new perl facility, I expect to develop and test using a private installation of perl, and not screw up my system's perl. It's the same with postgres. This is true whether you are a hard core developer or just someone writing a single module. cheers andrew
On Sat, 30 Jan 2010 22:25:32 -0200 Euler Taveira de Oliveira <euler@timbira.com> wrote: > Ivan Sergio Borgonovo escreveu: > > That's pretty expensive. > > > Ugh? > > > I mean... I just would like my .so end up with the expected name > > somewhere else. > It's just two command lines [1]. Consider I'm absolutely new to postgres C development. I'm pretty sure that what you're pointing at is not going to work unless you specify a bunch of other parameters. I've to count the time I've to spend to learn what is needed and and whenever I'll stumble into a bug/unexpected behaviour I'll have to take into account the time I'll spend wondering if I did miss to pass any parameter that caused that behaviour. Then I'm not aware of all the magic that pgxs and makefiles are doing. Once you ask... people direct you to pgxs. pgxs seems a good choice... a newcomer like me thinks... well that was made exactly to pick up all the information it needs from the environment and build my module. And it works and it is simple. > > Wouldn't it be better if make install could install stuff where I > > ask so I could put modules in different places *even* for the > > same installation of postgres? > Why do you want to mess your installation? Besides, you will need > to add the install path in dynamic_library_path and or the > absolute path to your CREATE FUNCTION script. Man, that's too much > work for a packager! Of course, you can always build on your way; > that's up to you. > > I mean... what's so weird about being able to develop postgres > > modules without requiring people build the whole postgresql or > > switching back and forward from root? > Ugh? You don't need root; I mean, you can always set absolute path > or even the dynamic_library_path [2] parameter. Absolute path requires that *the code* has to be different for every installation. dynamic_library_path looks more "interesting" if it spans just a connection, but still different version of pgxs gives different names to .so. If the absolute path could be set as a parameter passed to make that would be better. Anyway pg 8.3 make install change the name of libraries, so passing the absolute path depends on the version on which you're building. So it's not enough to write a "post processing" script that sed the install.sql. As said I'm able to write a script that will check if libmodule.so or module.so were generated and then "fix" the instal.sql[1], but still that's a workaround that may break in future versions... maybe postgres 9.0 will build libraries in a subdirectory of the source and then install will rename and move them with a different pattern. I think the most compelling reason for building postgres from source for people that would like to "occasionally" develop modules is having debug symbols. Maybe my point of view really sound alien to many in the hacker list since the learning curve to develop in C with postgres seems pretty selective so people here already decided to invest pretty much of their time into postgres... but many people may just would like to try. There are several shades of gray between "screwing my system postgres" and "test using a private installation". That's exactly why I'd like to keep my modules out of the system dir but still use the system postgres. I'm developing my module to see if it can serve a need of another project. What should I do then? make a private installation of apache and php as well? Develop my module on a private instance then deploy it in my test env, with system postgres for the other project then move it to the staging box... Costs add up, and right now I'd just like to try if I can come up with something useful. [1] that's exactly what I'm going to do. When I'll have a working module I'll see if that's enough for me or I want to do more complex work and I need a more advanced development environment. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Sat, Jan 30, 2010 at 04:50:11PM -0700, James William Pye wrote: > That install of PG that you're using will *probably not* have debugging information. > > Now, granted, you might not need PG with debugging for some problems, but > chances are that you'll come across one (or two or fifty or so) where you > *will* need it. Not just debug information (the --enable-debug flag to the configure script), but also --enable-cassert, --enable-depend, and/or others you're likely to want to use during development. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
* Andrew Dunstan <andrew@dunslane.net> [100130 19:55]: > If I am developing, say, a new > perl facility, I expect to develop and test using a private installation > of perl, and not screw up my system's perl. It's the same with postgres. But, perl was a bad example. If you're just trying to develop a new "perl module", something that other perl scripts can use, to require you to provide a completely private copy of complete perl, instead of the perfectly identical (other than paths) version the system provides is a bit much... I'm not arguing that the PGXS gripes Ivan has are valid, but your perl example probably *supports* his case more than you think... -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Aidan Van Dyk wrote: > * Andrew Dunstan <andrew@dunslane.net> [100130 19:55]: > > >> If I am developing, say, a new >> perl facility, I expect to develop and test using a private installation >> of perl, and not screw up my system's perl. It's the same with postgres. >> > > But, perl was a bad example. If you're just trying to develop a new > "perl module", something that other perl scripts can use, to require you > to provide a completely private copy of complete perl, instead of the > perfectly identical (other than paths) version the system provides is a > bit much... > > I'm not arguing that the PGXS gripes Ivan has are valid, but your perl > example probably *supports* his case more than you think... > > My example was not of a perl module, but of some extra facility inside the perl engine. But I take your point. OTOH, perl is not a running server, unlike Postgres. In any case, the points others have made about needing to develop against a build with cassert, debug and depends turned on are valid. cheers andrew
Ivan Sergio Borgonovo escreveu: > I'm pretty sure that what you're pointing at is not going to work > unless you specify a bunch of other parameters. > Ugh? Are you saying there is something wrong in our *official* documentation? It is just a normal compilation command; if you're a C programmer you'll have no problem. > Once you ask... people direct you to pgxs. pgxs seems a good > choice... a newcomer like me thinks... well that was made exactly to > pick up all the information it needs from the environment and build > my module. > Again, PGXS was developed to make packagers' life easier. Why on earth I want to install my library in a path different from $libdir? Packagers don't. Besides, PGXS won't work on Windows unless you're using a installation built using MinGW. > connection, but still different version of pgxs gives different > names to .so. > What the problem with that? If it set up the right name in sql file that's OK. IMHO, you're trying to complicate a simple process. If you messed up your installation you can always do: $ cd mymodule $ USE_PGXS=1 make uninstall -- Euler Taveira de Oliveira http://www.timbira.com/
On Sun, 31 Jan 2010 02:44:13 -0200 Euler Taveira de Oliveira <euler@timbira.com> wrote: > Ivan Sergio Borgonovo escreveu: > > I'm pretty sure that what you're pointing at is not going to work > > unless you specify a bunch of other parameters. > Ugh? Are you saying there is something wrong in our *official* > documentation? It is just a normal compilation command; if you're > a C programmer you'll have no problem. Well I think if I didn't have to compile for 8.3 I'd be more naturally guided to a solution since when make install does more than just moving files, you wonder if it is doing even more. I still don't know if make install is doing something more other than moving/renaming files. Still I think the documentation doesn't provide a reasonable path to *try* to write "Hello world". Actually there isn't even a "suggested" path that works unless you knock at pgsql-hackers and ask for details. Of course explanation on how to compile manually an extension without pgxs and a template makefile aren't sufficient. When I'd like to try something new I'd like to put myself in the most diffused, standard environment eg. one thing I'd like to avoid is choosing my own flavour of compile options. So... what's better than providing a template makefile? And there is one, and it works. But postgres makefile read module.sql.in and output module.sql. I'd consider module.sql.in part of the source of the project and I'd think it has to be "relocatable" without change. Now you use pgsx and it works great... You've your .so there, you look at the pattern used in the .sql, you adapt it and it still does work. Oh look! 8.3 change the .so name at make install. You adapt it once more but that makes you wonder... is make install doing something else? It would be better if: a) you document what make install is really doing or b) provided that contrib make install just move stuff around you let specify people where they would like to install the lib at make time so a sensible module.sql is produced b) looks easier to maintain and easier to use. But as said I may have a naïve idea of what really means providing a working build system for many architecture/OSes. No rocket science indeed. I'm not crying, I've already written mysimple script to just post-process module.sql. I'm describing my experience so you may be aware of the problems that new comers face. It is up to the people that will write actual code/docs to see if it is worth for them to do so. As soon as I'll feel comfortable to write something worth I'll write some docs. > > Once you ask... people direct you to pgxs. pgxs seems a good > > choice... a newcomer like me thinks... well that was made > > exactly to pick up all the information it needs from the > > environment and build my module. > Again, PGXS was developed to make packagers' life easier. Why on > earth I want to install my library in a path different from > $libdir? Packagers don't. Besides, PGXS won't work on Windows > unless you're using a installation built using MinGW. This is something like you bought a car to go from Paris to Berlin but you can't use it to go to Marseilles just because you don't have a map. pgxs and debian packages did a nearly perfect job even for my needs. Being able to compile and install an extension without a full dev environment and without being root has a non empty set of reasonable applications. Making easier to automate it out of the box doesn't look a bad thing. Sorry if it seemed I was complaining, I was trying to give feedback while learning my way to write "Hello world". -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote: > > When I'd like to try something new I'd like to put myself in the > most diffused, standard environment eg. one thing I'd like to avoid > is choosing my own flavour of compile options. > > This is just nonsense, as we have explained to you several times and you keep ignoring. The "standard" environment you're talking about will not have the compilation options enabled which are specifically designed to help developers. Why would anyone want to deprive themselves if that support? You have wasted far more of your time writing these emails than it would have taken you to set up a postgres development environment which you could have used *with* pgxs, because, depite being told what pgxs is for, you keep trying to make it do something it was not desinged for. If anyone is going from London to Paris via Marseilles it is you. cheers andrew
Hi, Ivan Sergio Borgonovo <mail@webthatworks.it> writes: > But considering that what it's really missing between what I need > and what I get is renaming a file... it's just a pain I've to set up > a whole new instance of postgres, install the whole source etc... Untrue. Get the sources with git clone, them ./configure --prefix=~/pgsql/master --enable-debug --enable-cassert make makeinstall Now you can add ~/pgsql/master to your PATH, initdb then pg_ctl start, and use PGXS. All will work just fine, and against a *devel* env. Not a production one. That's a clear *bonus*. > But well again... considering I'm a "rename" away from being able to > compile and test an extension with my user privileges... it's just a > pity it doesn't work that way out of the box. I think you're mixing up the development needs with the packaging ones. You have to keep separating them even when doing both. > Another scenario could be I could just svn update on a staging box, > compile there and then move everything to production easier. > Not every shop is a multimillion dollars enterprise that can afford > a dev/staging/production box for every version of postgres it is > using. > If you don't need to squeeze out every cpu cycle in a production box > you may be happy with a pre-packaged postgres. You want pre-packaged stuff, that does not mean you develop them on production servers. Virtual Machines and chroot etc are cheap. > still I think my need isn't that weird and could lower the entry > point for many developers quite a bit. Well you're only missing non-root make install with *packaged* PostgreSQL. As it stands, the 2 options are not compatible. But I fail to see how much it's a burden now that it's easy to develop on a dedicated *virtual* machine, e.g. > [1] and yeah I'll need dbg symbols but that's going to happen later. Development environment and production one are different. You seem to be wanting to ease the development on production environment. I'm not convinced this is a good way of approaching the problem. Regards, -- dim
Ivan Sergio Borgonovo <mail@webthatworks.it> writes: > Being able to compile and install an extension without a full dev > environment is nonsense. > and without being root That's easy on a development environment, but you keep insisting in not having one. Now that's your problem. > Sorry if it seemed I was complaining, I was trying to give feedback > while learning my way to write "Hello world". You seem to have a pretty clear idea of how you want things to work, and that has nothing to do with how they do. So you're confused at first, then you want to fix a non existent problem. Please step back, breathe, and look at your goal and problem again. Regards, -- dim
Ivan Sergio Borgonovo wrote: > Of course I can write a script that can workaround this. > It seems that the only thing missing is that pgxs 8.3 used to > prefix .so with lib and then rename them at install time, but pgxs > 8.4 build them directly without prefix. > I'm just speculating this is the issue and it is the only one I > still have to solve... but... what's going to happen next release? > Wouldn't it be better if make install could install stuff where I > ask so I could put modules in different places *even* for the same > installation of postgres? FWIW the soon-to-be-released PostGIS 1.5 has an "out of place" regression testing feature that allows PostGIS to be built using PGXS and regression tested without putting anything in the PostgreSQL installation directory itself. It's a little bit of a hack, but take a look at the PGXS makefile and the regression makefile to see how it all works: http://trac.osgeo.org/postgis/browser/trunk/postgis/Makefile.in http://trac.osgeo.org/postgis/browser/trunk/regress/Makefile.in HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
On Sun, 31 Jan 2010 22:24:40 +0000 Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk> wrote: > Ivan Sergio Borgonovo wrote: > > > Of course I can write a script that can workaround this. > > It seems that the only thing missing is that pgxs 8.3 used to > > prefix .so with lib and then rename them at install time, but > > pgxs 8.4 build them directly without prefix. > > I'm just speculating this is the issue and it is the only one I > > still have to solve... but... what's going to happen next > > release? Wouldn't it be better if make install could install > > stuff where I ask so I could put modules in different places > > *even* for the same installation of postgres? > FWIW the soon-to-be-released PostGIS 1.5 has an "out of place" > regression testing feature that allows PostGIS to be built using > PGXS and regression tested without putting anything in the > PostgreSQL installation directory itself. Thanks I'll give a look as soon as possible, now I'll try to concentrate on C development. I used something surely simpler. I wrote this small script and it actually does what I need. #!/bin/bash export USE_PGXS=1; make MODULE_big=$(sed -ne '/MODULE_big/s/^MODULE_big[ \t]*=[ \t]*\([^ \t]*\)/\1/gp' Makefile) so=$(ls -1 *"$MODULE_big"*.so) sed -e 's#\$libdir[^'"'"']*#'`pwd -P`'/'$so'#g' $MODULE_big.sql > $MODULE_big.l.sql sed -e 's#\$libdir[^'"'"']*#'`pwd -P`'/'$so'#g' uninstall_$MODULE_big.sql > uninstall_$MODULE_big.l.sql psql psql test < $MODULE_big.l.sql /* some more stuff to test functions */ And finally I have my first function working. Without other functions the extension isn't that useful yet but I think I'll be able to build something useful. Thanks for the help. Especially to RhodiumToad and klando on #postgresql I'll try to write some documentation shortly. -- Ivan Sergio Borgonovo http://www.webthatworks.it