pg.ddx.io pgsql-ru-general@postgresql.org mailing list archive
help / color / mirror / Atom feed=?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDt4PHy8O7p6g==?=
3+ messages / 2 participants
[nested] [flat]
* =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDt4PHy8O7p6g==?=
@ 2005-12-06 08:28 Serik <uge@pochtamt.ru>
0 siblings, 0 replies; 3+ messages in thread
From: Serik @ 2005-12-06 08:28 UTC (permalink / raw)
To: pgsql-ru-general
Здравствуйте, Nick.
Вы писали 6 декабря 2005 г., 2:58:47:
NG> Serik wrote:
>> Добрый день !
>>
>> Можно настроить PostgreSQL, чтобы запрос
>>
>> select 'test' || NULL || '' as ret;
>>
>> возвращал не пустую строку, а то, что есть ?
NG> Имманентным свойством NULL является "распространяемость" через
NG> выражения, то есть, любые выражения с NULL возвращают NULL. Если вы
NG> хотите иначе -- то это будет уже не NULL, а что-то другое. Пустая
NG> строка, например. Попробуйте сначала заменять NULL на пустую строку.
NG> Вообще хорошо бы получше сформулировать задачу.
Спасибо за ответ.
Задача совершенно простая, в таблице есть поля "фамилия", "имя",
"отчество".
Я хочу чтобы запрос возвратил мне одно поле "Фамилия И.О.", а
отчество может быть NULL, и соответственно возвращается пустая строка.
Стандартной функции на проверку строки на NULL, и замену на "" не
нашел. Написать свою ?
--
С уважением,
Serik
^ permalink raw reply [nested|flat] 3+ messages in thread
* =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDQ7uvoOiDz7/Dg4uvl7ejl?= =?Windows-1251?B?IOTu8fLz7+7sIOog5PDz4+jsIPDu6//sLiDQ7uvoIOrg6iDu4frl6vL7?= =?Windows-1251?B?IPHo8fLl7Psg4eXn7u/g8e3u8fLoLg==?=
@ 2008-07-02 09:15 sftf <sftf-misc@mail.ru>
1 sibling, 0 replies; 3+ messages in thread
From: sftf @ 2008-07-02 09:15 UTC (permalink / raw)
To: pgsql-ru-general@postgresql.org, "pronix pronix" <pronix.service@gmail.com>
pp> Посмотри ссылку - кажется это то, что вы ищете http://www.postgresql.org/docs/8.3/interactive/role-membership.html
Спасибо, но это не то.
Да, там идет речь о наследовании привелегий ролей.
Но нет механизма контроля прав доступа одной роли по отношению к другой.
Пример:
есть два менеджера с возможность создавать роли пользователей
СREATE ROLE manager1 LOGIN NOSUPERUSER CREATEROLE
СREATE ROLE manager2 LOGIN NOSUPERUSER CREATEROLE
и есть две созданные админом групповые роли
СREATE ROLE view_doc NOLOGIN NOSUPERUSER NOCREATEROLE
СREATE ROLE edit_doc NOLOGIN NOSUPERUSER NOCREATEROLE
Проблема №1: неуправляемые права ролей с привиоегией CREATEROLE по отношению к другим не суперюзерским ролям.
Например, manager1 и manager2 смогуть изменить или удалить роли
view_doc и edit_doc, что нежелательно. В ORACLE хотя бы можно не давать им ALATER ANY ROLE и DROP ANY ROLE.
Но даже этого недостаточно.
Далее, рассмотрим следующие действия менеджеров:
manager1:
СREATE ROLE user1 LOGIN NOSUPERUSER NOCREATEROLE -- manager1 создал сотрудника своего отдела
manager2:
СREATE ROLE user2 LOGIN NOSUPERUSER NOCREATEROLE -- manager2 создал сотрудника своего отдела
Теперь manager1 может изменить/удалить сотрудника "не своего отдела": ALTER ROLE user2...,
а manager2 тоже может изменить/удалить "чужого" сотрудника: ALTER ROLE user1...
Проблема №2: ограниченые возможности по котнролю присвоения ролей.
Рассмотрим вариант, когда manager1 должен иметь возможность раздавать только роль view_doc только своим сотрудникам.
manager1:
GRANT view_doc to user1
Однако он сможет сделать и так
GRANT view_doc to user2, чего быть не должно.
Нет возможности задать кому именно manager1 может раздать присвоенные ему самому роли.
Т.е. привелегия CREATEROLE слишком мощна и содержит в себе много привелегий.
Рассмотрим вариант менеджеров без привелегии CREATEROLE (т.е. NOCREATEROLE).
1. Они сразу же потеряют возможность создавать роли пользователей, а нам это нужно.
2. Если мы сделаем так, чтобы менджер хотя бы сам мог раздавать роли:
GRANT view_doc to manager1 with admin option
то тут две проюлемы:
a) manager1 сам дожен имет раздавемые им роли, что не всегда приемлемо
б) нет возможности управлять КОМУ ИМЕННО manager1 может назначить каждую имеющуюся у него роль
Итого: было бы хорошо, если бы роли могли выступать объектами, по отношению к которым назначаются права доступа.
Типа:
кто может создавaть | удалять какие роли
GRANT { { CREATE | DROP }
[,...] | ALL [ PRIVILEGES ] }
ON { {ROLE rolename [, ...]} | ANY ROLE}
TO { rolename } [, ...] [ WITH ADMIN OPTION ]
кто, что и в каких ролях может менять
GRANT ALTER { LOGIN | PASSWORD | INHERIT | RENAME | VALID | SET | и т.д. }
ON ROLE rolename [, ...]
TO { rolename } [, ...] [ WITH ADMIN OPTION ]
кто какие роли и кому может назначать
GRANT GRANT {ANY | rolename}
ON ROLE rolename [, ...]
TO { rolename } [, ...] [ WITH GRANT OPTION ]
^ permalink raw reply [nested|flat] 3+ messages in thread
* =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDQ7uvoOiDz7/Dg4uvl7ejl?= =?Windows-1251?B?IOTu8fLz7+7sIOog5PDz4+jsIPDu6//sLiDQ7uvoIOrg6iDu4frl6vL7?= =?Windows-1251?B?IPHo8fLl7Psg4eXn7u/g8e3u8fLoLg==?=
@ 2008-07-03 09:12 sftf <sftf-misc@mail.ru>
1 sibling, 0 replies; 3+ messages in thread
From: sftf @ 2008-07-03 09:12 UTC (permalink / raw)
To: Alexey Klyukin <alexk@commandprompt.com>; +Cc: pgsql-ru-general
AK> В данном примере роли пользователей (менеджеры отделов) по-моему относятся
AK> больше с пользовательскому приложению, а не к СУБД, соотвественно связь
AK> между менеджерами и другими пользователями можно сделать на уровне приложения.
В данном конкретном случае скорее да.
Однако если рассмотреть, как я считаю, вполне реалистичный вариант администрирования
БД (не приложения!) группой админов - каждый со своим "набором" подчиненных пользователей:
Главный админ
/ \
/ \
/ \
админ1 адимн2
/ | \ / | \
обычные пользователи1 обычные пользователи2
То тут весьма желателен механизм управления
"кто какими пользователями имеет право управлять и кто какими ролями имеет право распоряжаться".
"кто какими ролями имеет право распоряжаться" решить - дав эти роли админу с admin option, но
а) невозможно ограничить круг пользователей, которым админ1 может назначить имеющиеся у него самого роли
б) сами эти роли админу не часто не нужны - достаточно чтобы он мог ими распоряжаться, но не не имет эту роль
В приложении, наличие такого функионала в БД упростило бы его разработку.
Спасибо.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2008-07-03 09:12 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-06 08:28 =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDt4PHy8O7p6g==?= Serik <uge@pochtamt.ru>
2008-07-02 09:15 ` =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDQ7uvoOiDz7/Dg4uvl7ejl?= =?Windows-1251?B?IOTu8fLz7+7sIOog5PDz4+jsIPDu6//sLiDQ7uvoIOrg6iDu4frl6vL7?= =?Windows-1251?B?IPHo8fLl7Psg4eXn7u/g8e3u8fLoLg==?= sftf <sftf-misc@mail.ru>
2008-07-03 09:12 ` =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDQ7uvoOiDz7/Dg4uvl7ejl?= =?Windows-1251?B?IOTu8fLz7+7sIOog5PDz4+jsIPDu6//sLiDQ7uvoIOrg6iDu4frl6vL7?= =?Windows-1251?B?IPHo8fLl7Psg4eXn7u/g8e3u8fLoLg==?= sftf <sftf-misc@mail.ru>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox