<p dir="ltr"><br /> On Jun 10, 2014 7:05 PM, "Joshua D. Drake" <<a
href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>>wrote:<br /> ><br /> ><br /> > On 06/10/2014
07:02AM, Tom Lane wrote:<br /> >><br /> >> Gurjeet Singh <<a
href="mailto:gurjeet@singh.im">gurjeet@singh.im</a>>writes:<br /> >>><br /> >>> Startup scripts
arenot solely in the domain of packagers. End users<br /> >>> can also be expected to develop/edit their own
startupscripts.<br /> >><br /> >><br /> >>> Providing it as GUC would have given end users both
thepeices, but<br /> >>> with a compile-time option they have only one half of the solution;<br />
>>>except if they go compile their own binaries, which forces them into<br /> >>> being packagers.<br
/>>><br /> >><br /> >> I don't find that this argument holds any water at all. Anyone who's<br />
>>developing their own start script can be expected to manage recompiling<br /> >> Postgres.<br /> ><br
/>><br /> > This is certainly not true in any fashion. Production systems require a degree of flexibility and
configurationthat does not require the maintaining or compiling of source code.<br /> ><p dir="ltr">As JD surely
understands,it pains me a lot but I have to agree with him here.<p dir="ltr">There are also a non-trivial number of
organizationsthat just don't allow compilers on production boxes, adding another hurdle for those. We may think that's
ridiculous,and it may be, but it's reality.<p dir="ltr">That said, I agree that a guc is probably a bad idea. I like
theidea of an environment variable if we need it to be changeable. Or perhaps what we need is just better documentation
ofwhat's there already. Perhaps the documentation should have a section specifically aimed at packagers? <p
dir="ltr">/Magnus
