Tom Lane wrote:
> "Greg Stark" <stark@enterprisedb.com> writes:
>> On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> But of course case insensitivity isn't going to fix that example for you.
>>> So we're right back at the question of where we should draw the line in
>>> trying to accept variant input.
>
>> Well it's not a perfect precedent but for example, dd accepts:
>
>> G (2^30)
>> M (2^20)
>> k (2^10)
>> K (2^10)
>> Kb (10^3)
>> MB (10^6)
>> GB (10^9)
>> b (512)
>
> Hmm. I could get behind a proposal to allow single-letter abbreviations
> if it could be made to work across the board,
The SQL standard actually specifies something about that. You can
define the length of large object types (CLOB and BLOB) with multipliers
K, M, and G, as in
CREATE TABLE foo ( bar BLOB(5 M) );
These multipliers are case insensitive, of course. (And their are
1024-based, FWIW.)
So I could imagine that we generalize this approach to make these
multipliers available in other positions.
This would have definitional problems of its own, however. If you
interpret K, M, and G strictly as unit-less multipliers, then
SET shared_buffers = 2 G
would mean
SET shared_buffers = 2 * 1073741824
meaning
SET shared_buffers = 2147463648
which is not the same thing as the current
SET shared_buffer = '2GB'
This also affects the solution to another GUC units complaint that the
quotes are annoying, which I support.
We could possibly settle some of these arguments if we could redefine
all memory parameters to use one byte as base unit, and then allow some
ambiguity and unit omission from there. But that would probably cause
much havoc, so we are stuck with a certain degree of inconsistency anyhow.