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.
>  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.
In response to
pgsql-hackers by date
|Next:||From: Alex Hunsaker||Date: 2010-01-31 01:38:59|
|Subject: Re: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]|
|Previous:||From: Ivan Sergio Borgonovo||Date: 2010-01-31 00:38:41|
|Subject: Re: development setup and libdir|