> Tomasz Myrta <jasiek@klaster.net> writes:
> > [ Can't do SET SESSION AUTHORIZATION in a postgres-owned function ]
>
> That's because SET SESSION AUTHORIZATION looks to the original login
> userid, not the current effective userid, to decide whether you're
> allowed to do it. If it didn't work that way, a superuser couldn't
> switch to any other identity after becoming a nonprivileged user.
Does it mean, that SET SESSION AUTHORIZATION works the same for function
created with "security definer" as with "security invoker"? Are there any
other cases, when it doesn't work properly?
> I don't really see why you think this kluge is better than creating
> multiple database users, anyway ...
Well, it was just an idea. It is easier to keep all information about users
in one table "users" than synchronizing this table with pg_shadow via
usesysid and granting/revoking each user one by one (or adding them to
groups). It lets me also to give each user as little rights as needed - even
depending on which application they currently run (administration panel or
web report)
Regards,
Tomasz Myrta