Tom Lane wrote:
Table accesses done by a view are checked according to the privileges
of the owner of the view, not of whoever invoked the view. It's a
bit inconsistent because function calls done in the view are not handled
that way (though I hope we change them to match, someday).
Phew, sometimes I'm surprised about my own stupidity! I used this more
than once to create views that gave people access to tables they would
otherwise not be allowed to read, but I simply did not recognize that
it's simply the same in this case.
And by now I also found the section in the manual where this is
described (35.4, if someone is interested).
You can use "pg_dumpall -g" to get a dump of just global objects (roles
and tablespaces). If you do want to stick to hand-rolled scripts, then
Thanks, I didn't know this option. The next migration will be much
easier with this!
yeah, you need to take another look at it. Since 8.1 there is very
little difference between users and groups --- they are all roles, and
the only actual difference is the default settings of their LOGIN and
INHERITS flags. See the CREATE ROLE reference page for details.
Yes, I know the new role concept, but I didn't realize that it had these
impacts on my script. Anyway, I won't need it anymore, now that you told
me the "pg_dumpall -g" solution.
Thanks again,
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT and Consulting Fax: +49 551 489500-91
Hans-Böckler-Straße 2 http://www.deriva.de
D-37079 Göttingen
Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
