Simon Riggs wrote: > On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote: > >> * renamed wal_mode to wal_level > > I'm wondering whether this should be a list rather than an enum? If we > add something in the future that adds more info to WAL but doesn't fit > the one-dimensional model this implements then we could be in trouble. > Should this be > > e.g. wal_xxxx = feature2, feature3 > e.g. wal_xxxx = feature3 > e.g. wal_xxxx = feature1 > > recognising that some features require other features, so as an example > feature2 requires and implies feature1. > > The word "level" implies a one-dimensionality that "mode" did not and I > feel a little uncertain about that term.
That's the same concern Tom had at http://archives.postgresql.org/message-id/17411.1272291...@sss.pgh.pa.us. If we want to make it a list, I think it would be something like: wal_extra_info = '' # "archive", or "archive, hot_standby" That seems OK to me. Still, I'd like to go with "level", it's short and descriptive of the current options, and it's not that big a deal to rename it if we add more options in the future. It's hard to picture what the future options might be like. Someone had an idea years ago (you even?) to add more information like table names or primary keys to the WAL records, to make it easier to scrape information from the WAL for 3rd party replication solutions. Like feeding a slony replica from the WAL. Or maybe we'd want to fold full_page_writes to the new GUC. If it's just one or two extra feature orthogonal to the minimal-archive-hot_standby axis, it might still be best to keep the wal_level name, and make it possible to tack extra options to it like a list. Like "wal_level='archive, featureX'". "Level" would still be a good name, that's the main dimension. If the dependencies between the features get complicated, though, I doubt we can correctly guess the best representation for them now anyway. That's just my 2 cents, if others feel like "level" is painting us to the corner, "wal_mode" with the same values is the second best option IMO. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers