"Dave Page" <dpage@postgresql.org> writes:
> Yes, I know. Peter seemed to be saying that nothing except postgres
> itself should be in *any* of the installation directories

Yeah, that's what I think he said too, but it strikes me as a completely
bogus policy --- what about contrib modules or stuff from pgfoundry
or any random user-written module that was built with PGXS? All that
stuff happily drops files under $libdir and $sharedir, and I see no good
argument why it shouldn't.

There is fair room for argument about whether $sharedir is the
appropriate place for installation-specific config files though.
Those should probably live in the same place as postgresql.conf
and friends, ie, typically but not necessarily $PGDATA. It doesn't
look like SelectConfigFiles() saves the config directory name anyplace
where an add-on module could get at it. We could perhaps fix that for
8.3, but it won't help Mark if he insists on a backwards-compatible
solution. I suppose he could copy ConfigFileName and strip the last
component from it?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> Yeah, that's what I think he said too, but it strikes me as a completely
> bogus policy --- what about contrib modules or stuff from pgfoundry
> or any random user-written module that was built with PGXS? *All that
> stuff happily drops files under $libdir and $sharedir, and I see no good
> argument why it shouldn't.

We have an implicit policy for those two specific cases, which are OK with me.
I guess it's better to look at specific use cases instead of interpreting
other people's abstract directory descriptions. ;-)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(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