Thread: Is this a bug or a feature?

I'm trying to understand rules, because I'm about to use them
heavily in some research I'm doing on query optimization.
It seems a natural.

I've notices what looks like an anomaly.  I can define a rule
with two delete commands like this:

> CREATE RULE rule1 AS ON delete TO dummy DO INSTEAD
>    (delete from d2 where id=old.id; delete from d3 where id=old.id);

and it even works.

I can define a rule that does a random SELECT command like so:

>CREATE RULE rule2 AS ON insert TO dummy DO INSTEAD
>    select * from d2;

And this works too, although of course it looks odd.

But I cannot seem to get two selects in the same rule.  When I
try something like this:

> CREATE RULE rule3 AS ON insert TO dummy DO INSTEAD
>     (select * from d2; select * from d3;);

I get a complaint from the parser around the ; (it doesn't say
which ;).  The syntax looks like a direct parallel to the
syntax which worked for deletes, so I was hoping it would
work.

So the question becomes: is this a bug or a feature?
If it's a feature, I'd like it explained.  If it's a
bug, then I'll probably just go fix it.  I really want
to be able to put multiple queries in a rule so that
I can do weird things to them, time the results, and
call it research (thereby maybe earning a PhD).

I'm utterly new to PostgreSQL (did some stuff in
Oracle for my masters), so I'm not going to presume
I can tell at a glance whether this ought to work
or not.  I could use at least a little help.

If there's going to be a problem with doing this sort
of thing, I'd like to know as soon as possible so I
don't just bash my head on walls.

++ kevin


--
Kevin O'Gorman  (805) 650-6274  mailto:kogorman@pacbell.net
Permanent e-mail forwarder:  mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org
At school: mailto:kogorman@cs.ucsb.edu
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html

"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> But I cannot seem to get two selects in the same rule.
> So the question becomes: is this a bug or a feature?

The writer of the grammar seemed to think it was a feature, because
the productions for CREATE RULE go out of their way to prevent it.

I do not see any value in multiple SELECTs per se --- what are you
expecting will happen with the results of the additional SELECTs?
It does seem like some action queries with a SELECT as the tail end
would make perfect sense, although the grammar currently disallows
that.

I also do not see that it makes sense to allow a SELECT in a rule
that is for a non-SELECT event condition, though your examples show
that the system fails to enforce that.  The average client app would
not be prepared to see results coming back from a non-SELECT query,
so I think allowing this is not a good thing.

Finally, it'd probably be a good thing to implement semantic
restrictions like these in post-processing, not in grammar rules,
so that a message more meaningful than "parse error near ;" can
be reported.

Feel free to propose and implement a more consistent behavior...

            regards, tom lane