From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql-server/ ontrib/tablefunc/tablefunc.c oc/ ... |
Date: | 2004-02-04 04:15:05 |
Message-ID: | 5568.1075868105@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> Add some code to guc.c to allow these variables to be referenced by their
>> old names in SHOW and SET commands, for backwards compatibility.
> Does this mean that if you go ALTER USER/SET sort_mem TO xxx, it will
> set the variable work_mem=xxx in their pg_shadow row?
My first answer was "no, the pg_shadow row will still mention sort_mem,
but that will be accepted as meaning work_mem later on when you log in
as that user."
However, looking more closely, AlterUserSet converts option names to
canonical spelling before storing them, which means it Just Works:
regression=# create user foo;
CREATE USER
regression=# alter user foo set sort_mem = 999;
ALTER USER
regression=# select * from pg_shadow where usename = 'foo';
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
---------+----------+-------------+----------+-----------+--------+----------+----------------
foo | 100 | f | f | f | | | {work_mem=999}
(1 row)
Dang, sometimes nice things actually fall out of the code ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-05 22:12:51 | pgsql-server/src/bin/pg_dump Tag: REL7_3_STABL ... |
Previous Message | Christopher Kings-Lynne | 2004-02-04 02:31:05 | Re: pgsql-server/ ontrib/tablefunc/tablefunc.c oc/ ... |