Re: add server include files to default installation? - Mailing list pgsql-hackers

Dear Tom,

> > I wish to submit a small patch so that server includes and
> > all necessary configuration files could be installed *by default*.
>
> There is a reason why install-all-headers is not the default.

Sure. I hope so!

I'm questionning the pros and cons. I'm arguing that the cons against the
current situation are strong. Thanks for providing the pros, so it can be
discussed.

> It is that it shouldn't be the default: most people do not need it,

How will people know that they will not need it afterwards?

As far as I'm concerned, I noticed it afterwards:-(
I'm a pretty stupid user, but I'm sure I'm not the only one.

For instance several weeks after installing a pg, I wanted to test
tsearch2 on one database. What do I need to do? Well, basically I need a
full recompile, or at least a full extract of the sources, re-configure
and compilation of the relevant contrib part. When reconfiguring, I need
to remember what options I used.

Now, as someone trying to develop extensions, I need to rely on some sound
and extendable default installation.

> because they will never build any C extensions for themselves.

Hey, how do they know that before hand? They might need extensions. If
they need extensions, it is likely that they may have a C part. Most
contrib have a C part. External projects are likely to have a C part.
Some in user land (e.g. SPI_*), but not necessarilly.

Say aclitem accessor functions or new aggregates that may be needed for
some project that may be of interest to people. If there are not in, you
have to compile them. If the project cannot rely on the fact that
everything needed will be provided, it is no good.

> It would just be a waste of disk space for them.

2MB... that is less than 0.002 EUR.

Moreover, I do not think that it is wasted, especially as postgresql is
moving things outside the main project (pgfoundry, contrib, gborg). You
must help external projects to live if you want them to leave;-)

As a compromise, we can have two makefile targets, say "install" and
"light-install".

I argue that the default should be the one which enable later extensions.

> If we did do such a thing it would have zero impact on the majority of
> users anyway, because the RPM and other packagers will still put these
> files into separate postgresql-devel packages, which would still not be
> installed by default.

Thanks for this argument! If packagers do it (I know of BSD ports) it mean
that they think it is useful. So it should be the default for people who
*bother* to install pg by hand, so that they don't have to do it twice
because they did not notice this installation subtlety.

IMHO, it is the core business of postgresql to help external projects by
providing a usable default infrastructure for them. As another example of
this bad behavior, having external projects (pgadmin or phppgadmin) to
"parse" aclitem descriptors because you want to keep things opaque and
they need it anyway is damaging.

Thanks for you answer, have a nice day,

-- 
Fabien Coelho - coelho@cri.ensmp.fr