Andreas wrote:
>
> Since the copy statement is behaving differently than the normal select
> stuff,
> I think we should eighter introduce a new permission (name it copy or dump)
> or include the copy into the rewrite system.
>
> I would vote for the first and implement a new command:
> unload to <filename> [delimiter '|'] <select statement>; -- and
> load from <filename> [delimiter '|'] <insert statement>;
> that does behave like the select. (please forgive my Informix
> background)
Since the copy command checks for ACL_RD or ACL_WR on the
relation a user can use copy on any table, where he has
propper permissions.
And triggers are fired too on COPY FROM (thanks for the push
- found another place relevant for setuid triggers).
The only things not working for copy are rewrite rules. But I
think we should restrict rules to the view handling in the
future and move forward by implementing a pure and really
powerful procedural language.
I vote for leaving copy as it is and take a look if we can
fire triggers on SCAN which then could modify tuples instead
of using rules at all. If the time an ON SCAN trigger is
fired is just before the evaluation of any query
qualification and put down into the heap access methods,
anything should be fine except for performance maybe (but as
I usually say: don't force it - use a bigger hammer).
>
> As to the topic with setuid triggers and others, I think setuid procedures
> would be sufficient.
> These are implemented in Informix with the following simple syntax:
> create dba procedure ....
Looks good. Alternatively/additionally something like
ALTER FUNCTION funcname (argtypes) { SETUID | NOSETUID }
might be useful. Parser etc. steps could mostly be copied
from the DROP FUNCTION ... statement. And we have an unused
boolean attribute proistrusted in the pg_proc struct. If we
rename that to proissetuid anything is fine.
As I said I already fiddled around with that and got setuid
functions and triggers working (don't ask for code - usually
I make a copy of the source tree, hack in totally ugly things
until I know how to do it and throw anything away to be sure
only development not hacking get's into PostgreSQL).
Until later, Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
