Michael Robinson wrote:
> The reason people want an embedded procedural language is because procedures
> in such a language have access to the guts of the backend, and can perform
> many operations much more efficiently than having to go push everything
> through the FE->SQL->compiler->executor->tuple list->FE->lather->rinse->repeat
> bottleneck.
That's one reason. Another one is that you can create stored
procedures that get triggered on events
(INSERT/UPDATE/DELETE) and can perform referential integrity
checks and other things then.
Some of them could also be done by constraints (if we
sometimes have the rule system powerful enought to do it
correctly). Some can't.
>
> I decided that the proper solution was to expose all the internal guts of
> the backend through a proper CORBA interface. That way, any language with
> an ORB could act as an embedded procedural language.
And how does your CORBA get triggered in the case someone
uses the good old psql? Or MUST everything then talk CORBA
and you disable any other kind of access completely? Note
that for a trigger that has to ensure referential integrity
it's not enough to say "it will be triggered if the user uses
the correct access path". It has to ensure that the user
doesn't use the wrong one!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
