> > The FreeBSD database/postgres* ports depend on them. Which is probably
> > why Marc insists on keeping them.
>
> Well, I think that's a horrid dependency to have. Other packaging
> systems (e.g. the RPM builds) seem quite able to split up a single
> unified build into multiple packages - what can't FBSD? What would we do
> if some other packaging system wanted to ask us for a different split?
I am not particularly impressed with the FreeBSD database/postgres*
ports. The emphasis on splitting postgres into -server -client and -
contrib packages, while in keeping with the rest of the ports
collection seems misplaced when you consider that they offer no
mechanism (at least of which I am aware) to support multiple versions
of the binary.
I can't imagine a situation where I would care about having separate
packages, aside from being annoyed that some of the more valuable
stuff in contrib is not built / installed. Does anyone operate a
production environment without at least pgstattuple? On the other
hand, every production server I've worked on has had at least 2 binary
packages installed and ready for use at all times (the current build
and the last production build in case we're forced to roll back). In
many cases servers I've worked on have had multiple back-ends running,
often with different binaries.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
