Thread: orderRules() now a bad idea?
I just noticed that rewriteHandler.c contains a subroutine orderRules()
that reorders the rules for a relation into the ordernon-instead rulesqualified instead rulesunqualified 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.
regards, tom lane
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. Unless Jan has an objection, I think alpha is best, because it matches trigger rule odering. That original rule ordering isn't something anyone is going to figure out on their own. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@Yahoo.com #
Bruce Momjian writes: > Unless Jan has an objection, I think alpha is best, because it matches > trigger rule odering. That original rule ordering isn't something > anyone is going to figure out on their own. But alphabetical? According to whose definition of the alphabet? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> But alphabetical? According to whose definition of the alphabet?
It looks like NAME comparison uses strcmp (actually strncmp). So it'll
be numeric byte-code order.
There's no particular reason we couldn't make that be strcoll instead,
I suppose, except perhaps speed.
regards, tom lane
Tom Lane writes: > > But alphabetical? According to whose definition of the alphabet? > > It looks like NAME comparison uses strcmp (actually strncmp). So it'll > be numeric byte-code order. > > There's no particular reason we couldn't make that be strcoll instead, > I suppose, except perhaps speed. But how will this work when we have per-column/datum collation order? And what about languages that don't have any useful collation order for their alphabets (far east)? ISTM that a globally viable feature of this sort would have to sort by something numeric. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> It looks like NAME comparison uses strcmp (actually strncmp). So it'll
>> be numeric byte-code order.
>> There's no particular reason we couldn't make that be strcoll instead,
>> I suppose, except perhaps speed.
> But how will this work when we have per-column/datum collation order?
> And what about languages that don't have any useful collation order for
> their alphabets (far east)? ISTM that a globally viable feature of this
> sort would have to sort by something numeric.
I'm confused; are you saying that NAME's sort behavior is good as-is?
If not, what would you have it do differently?
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Tom Lane writes: > >> It looks like NAME comparison uses strcmp (actually strncmp). So it'll > >> be numeric byte-code order. > >> There's no particular reason we couldn't make that be strcoll instead, > >> I suppose, except perhaps speed. > > > But how will this work when we have per-column/datum collation order? > > And what about languages that don't have any useful collation order for > > their alphabets (far east)? ISTM that a globally viable feature of this > > sort would have to sort by something numeric. > > I'm confused; are you saying that NAME's sort behavior is good as-is? > If not, what would you have it do differently? Yes, exotic ordering of rules just doesn't seem warranted. I think it should match the ordering of pg_class.name, which is strcmp() already. Let's do ASCII ordering (strcmp) and see how things go. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane writes: > I'm confused; are you saying that NAME's sort behavior is good as-is? > If not, what would you have it do differently? What I am primarily saying is that ordering the rule execution order alphabetically is not a really good solution. Consequently, I would not go out of my way to make code changes to pursue this goal. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Tom Lane writes: > > > I'm confused; are you saying that NAME's sort behavior is good as-is? > > If not, what would you have it do differently? > > What I am primarily saying is that ordering the rule execution order > alphabetically is not a really good solution. Consequently, I would not > go out of my way to make code changes to pursue this goal. Well, it seems to make the users happy, so that's good enough for me. There was particular concern from users about what values are returned when multiple rules or multi-statement rules are fired, and ordering them by ASCII order does give them the tools needed to get the job done. We already order NAME by strcmp, so I don't see how we are breaking anything by doing the same for rules. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I'm confused; are you saying that NAME's sort behavior is good as-is?
>> If not, what would you have it do differently?
> What I am primarily saying is that ordering the rule execution order
> alphabetically is not a really good solution. Consequently, I would not
> go out of my way to make code changes to pursue this goal.
I think what you are really driving at is that you'd like to have some
other mechanism than choice-of-rule-name for users to determine ordering
of rule expansion. That's a fair enough objection, but you'd still need
to get rid of orderRules() along the way. Unless you *like* ordering
restrictions that were made purely for implementation convenience?
regards, tom lane