Bruce Momjian <[EMAIL PROTECTED]> writes:
>> This patch incorporates a number of changes suggested by the group. The
>> purpose of this patch is to move postgresql to a position where all
>> configuration options are specified in one place. The postgresql.conf file
>> could completely document a postgresql environment.

AFAICS this patch breaks standalone backends, since the smarts involved
in dealing with the new flavors of directory layouts were not taught to

The documentation is rather lacking as well.  "include" is not really a
variable and should not be documented as if it were --- for one thing,
that leaves the reader wondering if he can only specify it once.  The
other added variables are insufficiently doc'd because there is no
explanation of the defaults.  Also I should think that somewhere in the
admin guide there should be an explanation of the different ways you can
lay out the files and why you might choose different ones.  It's also
highly unclear how you get such a setup established, when there's been
no change in the behavior of initdb.

ProcessConfigFile will dump core on out-of-memory (test for malloc
failure is in the wrong place).  I also think some memory leaks have
been introduced in ReadConfigFile.

The whole concept of a "function" GUC variable seems very ill-advised to
me; for one thing, what will "show include" or "set include" do?  Can a
user do ALTER USER SET include = foo?  I think it would have been better
to hard-wire the handling of 'include' in the guc file reader, and not
try to make it act like a variable.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to