wieck@debis.com (Jan Wieck) writes:
> 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.
Yes, this is true. However, between SQL, and PL/PGSQL, I think we have
this covered, and I don't see a lot of urgency for adding new languages
just for this purpose.
> 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!
Well, that's the nice thing about ORBit. You can link two CORBA-connected
systems into one binary, and ORBit will give a clean and efficient in-process
connection between the two. So, just as pgsql can expose it's guts via
CORBA, so, too, can the programming runtime of your choice. All that's
required (in theory) is a one-time wrapper for pgsql's current embedded-
language API, and you don't have to mess with the pgsql side ever again. Of
course, this win only applies to languages with ORBit bindings (currently C,
with C++, Python, Ada, and several others in the pipeline).
But, again, I don't see a lot of urgency for this kind of solution.
-Michael Robinson