Re: AW: [HACKERS] Re: PostgreSQL reference manual

Bruce Momjian writes:
> > Stephane Lajeunesse writes:
> > > > A create group <groupname> is still missing in the grammar,
> > >
> > > I'm working on this.. Should have something working around the end of
> > > this week (for ALTER USER and CREATE USER).
> >
> > Please let me use this to tell you all that I would like to get notice of
> > each change to gram.y. I am currently modelling ecpg's parser after gram.y
> > to get good syntax checking. So I have to make these changes, too.
>
> Good idea on telling you of each change, but I also recommend that every
> time you update the ecpg grammer, you save a copy the gram.y that you
> used to do it, so later when you need to get it back in sync, you can do
> a diff on the old and new one to see each change so you don't miss any.

Consider also not updateing the grammar. The strength of PostgreSQL is that
functions can be added to work inside the server. These functions can often
do whatever is being proposed as new syntax.

So, instead of cluttering up the grammar with non-standard SQLish stuff
to handle things like groups, just create an administrative function to
do this job.

* return create_group('groupname');
* return add_user_to_group('groupname', 'username');
* return drop_group('groupname');

These can be written in C, in SQL, or what ever far more quickly and with
much less risk of destabilizing the system than the parser can be modified.
It also avoids making incompatibility with ecpg.

And, in keeping with the recent anti-bloat thread, these can be loadable
extensions, not part of the core. So if you don't use groups, you don't pay
for them.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.