Re: Smaller access privilege changes
От | Tom Lane |
---|---|
Тема | Re: Smaller access privilege changes |
Дата | |
Msg-id | 29618.990708155@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Smaller access privilege changes (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Smaller access privilege changes
|
Список | 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 по дате отправления: