Re: [GENERAL] restore error - language "plperlu" is not trusted
| От | Peter Eisentraut |
|---|---|
| Тема | Re: [GENERAL] restore error - language "plperlu" is not trusted |
| Дата | |
| Msg-id | 200312182128.51521.peter_e@gmx.net обсуждение |
| Ответы |
Re: [GENERAL] restore error - language "plperlu" is not trusted
|
| Список | pgsql-patches |
Attached is my proposed patch for this problem, to be put in 7.4.1. Please someone give it a quick check. Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Tom Lane wrote: > >> Uh, no, because you can say something like > >> revoke all on language plperlu from public; > >> and end up with non-null lanacl (because it instantiates the > >> default assumption that the owner has all privileges). > > > > OK, that needs to be disallowed. > > Fair enough. I thought it was a bit odd to disallow GRANT but allow > REVOKE anyway. > > >> We could possibly hack the backend to avoid that, but I think > >> pg_dump will need the special-case test anyway since it has to be > >> able to cope with existing databases, wherein lanacl may be > >> non-null. > > > > So far we know of 1 such database. I'd like to see some more > > before we bother about it. > > It's a one-line addition --- just put the dumpACL call inside > "if (lanpltrusted)". I think it is a reasonable change. We'd have > to do something anyway, because the existing pg_dump code is > certainly broken for dumping untrusted languages from pre-7.3 > databases (it assumes a nonempty lanacl setting in that case).
Вложения
В списке pgsql-patches по дате отправления: