Create Group

I'm currently working on Create/Alter/Drop Group statements. I have all
the framework set up, I can create empty groups and drop them, and create
all sorts of notices about unimplemented functionality.

First, the syntax I had in mind:

CREATE GROUP name [ WITH [ SYSID id ] [ USER name1, name2, ... ] ]
ALTER GROUP name WITH SYSID id /* changes sysid */
ALTER GROUP name ADD USER name1, name2, ...
ALTER GROUP name DROP USER name1, name2, ...
DROP GROUP name

Please protest now or hold your peace for at least one release. :)

Here's a tricky problem:
=> insert into pg_group values ('one', 1, NULL);
=> create group two;
both create groups of identical fashion. The create group uses
heap_insert().

Now I do
template1=> alter group one add user foo;
NOTICE: Cannot add users to a group, yet.
ALTER USER
/* OK */
template1=> alter group two add user foo;
AlterGroup: Group "two" does not exist.
/* Huh? */

This is caused by this statement:
if (!HeapTupleIsValid(
SearchSysCacheTuple(GRONAME, PointerGetDatum(stmt->name), 0, 0, 0))
)
{
heap_close(pg_group_rel, AccessExclusiveLock);
UserAbortTransactionBlock();
elog(ERROR, "AlterGroup: Group \"%s\" does not exist.",
stmt->name);
}

However:

template1=> select * from pg_group;
groname,grosysid,grolist
one,0,
two,1,

However however:

template1=> select * from pg_group where groname='two';
groname,grosysid,grolist
(0 rows)

BUT:

template1=> drop group two;
DROP GROUP
template1=> drop group two;
ERROR: DropGroup: Group "two" does not exist.
as expected.

DropGroup does a normal heap_scan checking for the existence of the
groups. I'm not sure, is there some subtle binary off-by-one-bit problem,
are the strings encoded differently, etc.?

Interestingly, this similar statement works:

tuple = SearchSysCacheTuple(SHADOWNAME, PointerGetDatum(stmt->user), 0, 0, 0);
if (!HeapTupleIsValid(tuple))
{
heap_close(pg_shadow_rel, AccessExclusiveLock);
UserAbortTransactionBlock();
elog(ERROR, "AlterUser: user \"%s\" does not exist", stmt->user);
}

Also, why can pg_group not be vacuumed? (pg_shadow can.) With all this
testing, mine is filling up.

Perhaps related, but just out of curiosity: Why is pg_group a system
relatation (pg_class.relkind='s')? Only three other ones have this
set: pg_variable, pg_log, and pg_xactlog.

Any help will be appreciated. I'll be back when I need to figure out the
arrays. :)

(Patch is included for those that don't have a clue what I'm talking about
but would like to find out anyway.)

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden