Re: pgsql-server/ ontrib/tablefunc/tablefunc.c oc/ ...

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

In response to

Browse pgsql-committers by date

  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/ ...