> I suspect you are assuming that
> WHERE not szalllev_szamla_szamla_kapcs(new.szamla,new.tetelszam)
> will be executed only after the constraints in your UPDATE'S WHERE
> clause, but the planner just sees them all as a big heap of constraints,
> and executes them in whatever order it thinks will be efficient.
I see. Yes, I thought that the constraints in my UPDATE's WHERE clause are
executed first, and then the WHERE clause in the RULE. As I can understand
you, there is no way for me to force the planner to make the order of the
execution of these constraints: these constraints are completely coequal.
Presumably the base of the PostgreSQL engine doesn't support (and probably
will never support) hierarchy in constraints. I quickly read the
documentation about this (at RULEs versus TRIGGERs) but I hadn't found
anything. So probably it would be good to write some words about this. It
also would be good to include your note about the conditional RULEs (i.e.
all possibilities must be covered).
> If you are building a design in which such functions might have
> side-effects, then you'd better reconsider your design.
Well, first I wanted to write triggers but this seemed to be easier.
I will try to give a last chance to the rules and if it is not
successful, I will go back to the triggers... :-)
Thank you for your help. Your quick and deep explanations make me
PostgreSQL the most useful database server in the world.
Congratulations for the excellent work of the PostgreSQL team! ;-)
Zoltan