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.

			regards, tom lane

Mon, 14 Oct 2002 15:13:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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.

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, Pennsylvania 19073

Mon, 14 Oct 2002 18:53:27 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
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@Yahoo.com #

Tue, 15 Oct 2002 09:33:38 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: orderRules() now a bad idea?
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


Tue, 15 Oct 2002 20:53:50 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: orderRules() now a bad idea?
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

Tue, 15 Oct 2002 16:36:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: orderRules() now a bad idea? 
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


Thu, 17 Oct 2002 00:11:53 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: orderRules() now a bad idea? 
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

Thu, 17 Oct 2002 00:21:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: orderRules() now a bad idea? 
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, Pennsylvania 19073

Thu, 17 Oct 2002 14:54:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: orderRules() now a bad idea?
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


Thu, 17 Oct 2002 21:17:07 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: orderRules() now a bad idea? 
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, Pennsylvania 19073

Thu, 17 Oct 2002 15:17:09 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: orderRules() now a bad idea?
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

Thu, 17 Oct 2002 23:38:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: orderRules() now a bad idea? 