...
> If you're suggesting setting up an actual database table, I'm not
> sure I see the point. Any system parameter is going to have to be
> tied to backend code that knows what to do with the parameter, so
> it's not like you can expect to do anything useful purely by adding
> table entries. The C-code tables existing inside guc.c seem like
> enough flexibility to me.
Ah, certainly not! (which is as close as I'll come to saying "how
foolish!" :)
You've done work on generalizing the extensibility features of
PostgreSQL. A next step to take with that is to allow for a more generic
"package" capability, where packages can be defined, and can have some
initialization code run at the time the database starts up. This would
allow packages to have their own internal state as extensions to the
internal state of the core package.
Having SET be extensible is another piece to the puzzle, allowing these
kinds of parameters to also be extensible. I'm not sure that this should
be considered a part of the GUC design (the parameters are designed to
be available *outside* the database itself, to allow startup issues to
be avoided, right?) but perhaps GUC should be considered a subset of the
actual SET feature set.
I got the strong feeling that Hiroshi was concerned that we were
intending to lump all SET features into a single one-size-fits-all
framework. This may be the flip side of it; just because we like SET to
be used in lots of places doesn't mean we should always limit it to
things built in to the core. And we should be wary of forcing all things
"SET" to behave with transactional properties if that doesn't make
sense. I've always been comfortable with the concept of "out of band"
behavior, which I think is reflected, for example, with DDL vs DML
aspects of the SQL language. Current SET behavior aside (where the
parser is rejecting SET commands out of hand after errors within a
transaction) we should put as few *designed in* restrictions on SET as
possible, at least until we are willing to introduce a richer set of
commands (that is, something in addition to SET) as alternatives.
all imho of course :)
- Thomas
