Re: Smaller access privilege changes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Smaller access privilege changes
Date
Msg-id 29618.990708155@sss.pgh.pa.us
Whole thread Raw
In response to Re: Smaller access privilege changes  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Smaller access privilege changes  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> 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.

My thought exactly.  If we were going straight to full SQL compliance
then I wouldn't worry, but I don't like the idea of breaking apps now
and then breaking them some more later.

A different tack is to go ahead and make the change now, but try to
ensure we won't have to change the coding again when we do the rest of
the SQL protection model.  Do you know what is still missing given this
change?

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

What if the prior test crashed or was aborted by the user midway
through?  Cleaning up at the end of the test is good, but I think
it'd be wise for pg_regress to also drop these users/groups before
it starts the run.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Smaller access privilege changes
Next
From: Don Baccus
Date:
Subject: Re: Plans for solving the VACUUM problem