Tom Lane writes:
> > * rename the internal representation: s = select, i = insert, u = update,
> > d = delete, R = rules
>
> Since the internal representation is visible to users, I fear that a
> wholesale renaming will break existing applications. Can we make this
> part of the change less intrusive?
I guess so. I could make r=select, a=insert, w=update, d=delete, R=rules,
x=reference. Of course we will have to break this eventually, but we
might as well put it off until then.
> > * Implement SQL REFERENCES privilege: grant references on A to B will
> > allow user B to create a foreign key referencing table A as primary key.
>
> Which privilege will SELECT FOR UPDATE require, and how do you plan to
> get the system to distinguish users' SELECT FOR UPDATE from the commands
> issued by the foreign key triggers?
The REFERENCES privilege will be checked by CREATE TABLE and ALTER TABLE
(where it currently says "must be owner"). SELECT FOR UPDATE is not
affected by this and will stay the way it is.
> > I'd also like to create a regression test. That will require creating
> > some global users and groups in the installation where the test runs. I
> > think as long as we name them "regressuser1", "regressgroup2", etc. this
> > won't harm anyone.
>
> Seems reasonable, but be careful to cope with the case where these
> objects already exist from a prior regression run.
I drop them at the end of the test.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
