Jim C. Nasby wrote:
> While marking up TODO for potential new-hacker items I've run across
> some items that probably need more explanation:
>
> o Allow commenting of variables in postgresql.conf to restore them
> to defaults
>
> This doesn't work already?
The idea here is the when you comment something out, it should restore
its default. Right now it keeps the previously uncommented out value,
which confuses people.
New text is:
o Allow commenting of variables in postgresql.conf to restore them to defaults
Currently, if a variable is commented out, it keeps the previous uncommented value until a server
restarted.
> * Allow triggers to be disabled [trigger]
>
> Isn't this going to be in 8.1?
Yes, just marked it as done because it went into CVS 12 hours ago.
> * SQL*Net listener that makes PostgreSQL appear as an Oracle database
> to clients
>
> Any reason not to do this for other databases; notably MySQL?
I suppose, but no one has asked for it, while they have for Oracle.
>
> o Do VACUUM FULL if table is nearly empty?
>
> Since that results in an exclusive table lock (which is vastly different
> from regular vacuum), wouldn't it be better to just throw a warning?
Good point. I guess that's why the question mark was there. New text:
o Suggest a VACUUM FULL if table is nearly empty
> * Reduce WAL traffic so only modified values are written rather than
> entire rows?
>
> Shouldn't this be marked as depending on eliminate need to write full
> pages? (At least ISTM it won't do any good as long as we're writing full
> pages)
Not really --- the per-row writes and the full page writes are two
different operations for two different purposes. The first is for WAL
crash recovery, the second is to prevent partial page writes.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073