Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA33458; Sat, 26 Feb 2000 20:47:13 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA22651; Sat, 26 Feb 2000 20:47:08 -0500 (EST) To: "Stephen Martin" cc: pgsql-interfaces@postgreSQL.org, pgsql-hackers@postgreSQL.org Subject: Re: [INTERFACES] Date: Sat, 26 Feb 2000 17:01:55 -0800 In-reply-to: References: Comments: In-reply-to "Stephen Martin" message dated "Sat, 26 Feb 2000 19:59:46 -0500" Date: Sat, 26 Feb 2000 20:47:08 -0500 Message-ID: <22648.951616028@sss.pgh.pa.us> From: Tom Lane "Stephen Martin" writes: > For example I have a postgres id 'www' present within my pg_shadow/pg_user. > I recently installed a package and inadvertantly created another 'www' user. > How can I > 1) Ensure I canot in future create duplicate names? There should probably be a unique index on pg_shadow's usename field, and another one on the usesysid field (otherwise there's not a unique map from sysids to users, which is bad since we use sysids as referential keys in other tables). I'm surprised this hasn't been pointed out before :-( I'm not sure how difficult it would be to do it. Just creating an index with CREATE INDEX will not work, because pg_shadow is an installation-wide table and its index must be as well. There's some routine somewhere in the backend that would have to be taught about the index. regards, tom lane