On Tue, 19 Feb 2002, Eric Veldhuyzen wrote:
> On Tue, Feb 19, 2002 at 02:29:05PM +0100, Helge Bahmann wrote:
> > Nevertheless anything that could be checked in procedures can also be
> > checked in query rewrite rules, although it may look unfamiliar if
> > you have never done this. The standard way of doing this is the
> > following:
>
> Not really. A procedure can receive parameters that are not inserted in the
> table, or it can even insert data into various tables the same time.
Using views and rules to do access checking does not prevent you
from writing procedures that combine several operations.
(oh and btw: you could in theory include "artificial" columns in the views
and evaluate their value without inserting it into the underlying table
but this is really messy; and you can perform multiple actions in
a rule)
Look at it this way:
- if your data integrity and consistency constraints cannot easily be
expressed in relational terms, a relational database may not be the best
tool to solve your problem
- if, conversely, you can express these constraints in relational terms,
then the required functionality can generally be provided using views, rules
and triggers; your "procedures" in this case are just convenient helper
functions and do not need to perform any checking
This is not to say that something like setuid functions are useless, they
would occasionally still come in handy for some very specific trigger
procedures...
Best regards
--
Helge Bahmann <bahmann@math.tu-freiberg.de> /| \__
Network admin, systems programmer /_|____\
_/\ | __)
$ ./configure \\ \|__/__|
checking whether build environment is sane... yes \\/___/ |
checking for AIX... no (we already did this) |