Andrew Dunstan <[EMAIL PROTECTED]> writes:
> All this discussion seems to me to be going off into the clouds, where
> every objection is met with some still more elaborate scheme. I think we
> need to look at simple, incremental, and if possible backwards
> compatible changes.
+1. Let me propose the simplest possible scheme, namely
The SQL-exposed function knows how to find and replace the definition
of a variable (commented or otherwise) in the primary configuration
file. It does not chase INCLUDEs. If it doesn't find the target
variable anyplace in the primary file, it errors out.
What this would mean is that for people using configuration include
files (which is surely a tiny minority), anything tucked away in an
include file is not editable from a SQL session. This gives them the
flexibility to decide which things are editable and which aren't, and by
removing items from the base config file and/or rearranging the ordering
of includes, they can control which things can be overridden from SQL.
In particular, this works conveniently for the case where the base
config file is in $PGDATA and is postgres-writable, whereas the include
file(s) are shared across database clusters and are not writable.
I think that's the most obvious use-case for having an include file.
regards, tom lane
---------------------------(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
