ОШИБКА: отказано в разрешении для схемы user1_gmail_com с символом 46
Как я могу получить путь к файлу из этого типа URI контента?
У вас нет, так как нет никакого файла вообще за
Uri, не говоря уже о том, к которому вы можете получить доступ. ЭтоUriможет указывать на:
- Локальный файл на внешнем хранилище
- Локальный файл на внутренней памяти для другого приложения
- Локальный файл на съемном носителе
- Локальный файл, который зашифрован и должен быть дешифрован на лету
- Поток байтов, хранящихся в столбце
BLOBв базе данных- Часть содержимого, которое должно быть загружено другим приложением первым
- ... и т. д.
Все другие приложения, такие как Facebook, Google+ это делает
Нет, это не так. Они используют
ContentResolverи:
openInputStream()для чтения в байтах, связанных с содержимымgetType(), чтобы получить тип MIME, связанный с содержимымquery()иOpenableColumns, чтобы получить размер и отображаемое имя, связанные с контентом
3 ответа
Вам необходимо предоставить доступ не только к таблицам в схеме, но и к самой схеме.
По умолчанию пользователи не могут получить доступ к любым объектам в схемах, которые им не принадлежат. Для этого владелец схемы должен предоставить привилегию USAGE для схемы.
Так что либо сделайте созданного пользователя владельцем схемы, либо предоставьте пользователю USAGE для этой схемы.
Это смутило меня. Все еще не уверен, что я обращаюсь с этим правильно. Запустите \h grant для синтаксиса в psql. Вот как мне удалось заставить других моих пользователей и группы работать так, как мне нужно:
GRANT ALL PRIVILEGES ON SCHEMA foo TO GROUP bar;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO GROUP bar;
Я продолжал получать эту ошибку при использовании flyway для развертывания изменений базы данных. Сначала я делаю ручную настройку, например, создаю базу данных, так что flyway не понадобятся эти разрешения супер-администратора.
Мое исправление
Я должен был убедиться, что пользователь базы данных, который использовал задание на прохождении, имел права собственности на общедоступную схему, чтобы затем пользователь мог назначить право на использование Схема для других ролей.
Дополнительные сведения о настройке
Я использую AWS RDS (как обычную, так и Aurora), и они не позволяют суперпользователям в базах данных. RDS резервирует суперпользователей только для использования AWS, так что потребители не могут сломать встроенную репликацию. Однако есть ловушка-22, которую вы должны быть владельцем postgres, чтобы иметь возможность ее изменять.
Мое решение состояло в том, чтобы создать роль, которая действует как владелец («роль владельца»), а затем назначить и моего администратора, и пользователя flyway для роли владельца, и использовать сценарии ALTER для каждого объекта, чтобы назначить владелец объекта в роли владельца.
Я пропустил общедоступную схему, поскольку она была создана автоматически при создании сценария базы данных вручную. В общедоступной схеме по умолчанию используется моя роль администратора, а не роль общего владельца. Поэтому, когда пользователь пролетного пути пытался назначить права доступа к общей схеме другим ролям, у него не было на это полномочий. Однако ошибка не возникла во время выполнения пролетного пути.