Re: orderRules() now a bad idea?

Tom Lane wrote:
>
> I just noticed that rewriteHandler.c contains a subroutine orderRules()
> that reorders the rules for a relation into the order
> non-instead rules
> qualified instead rules
> unqualified instead rules
> This conflicts with the feature we'd added to 7.3 to fire rules in
> alphabetical order. (What will presently happen is they'll be fired
> alphabetically in each of these categories.)
>
> I see that the logic in fireRules() assumes that rules are processed in
> this order, but that would be fairly easy to fix. Is there any other
> good reason for doing this reordering? I'd like to remove orderRules()
> and implement straight alphabetical ordering.

I don't see a strong reason why not doing it the way you propose. It's
just that you need to keep a version of the parsetree before you applied
an unqualified instead rule just for the case that you later need to
apply one of the others. But this copy shall not make it into the final
list of queries.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #