Thread: Re: [PATCHES] Updatable views

Bernd Helmle <mailings@oopsware.de> writes:
> While working on Alvaro's suggestions to fix the code i got the opinion
> that we need to reject any attempts to name a user defined rule
> as

> "_INSERT"
> "_NOTHING_INSERT"
> "_DELETE"
> "_NOTHING_DELETE"
> "_UPDATE"
> "_NOTHING_UPDATE"

If the code is dependent on recognizing names to know what it's doing,
then I'd say you have a fundamentally broken approach.  Consider adding
a flag column to pg_rewrite to distinguish these rules, instead.

            regards, tom lane

On 8/24/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bernd Helmle <mailings@oopsware.de> writes:
> > While working on Alvaro's suggestions to fix the code i got the opinion
> > that we need to reject any attempts to name a user defined rule
> > as
>
> > "_INSERT"
> > "_NOTHING_INSERT"
> > "_DELETE"
> > "_NOTHING_DELETE"
> > "_UPDATE"
> > "_NOTHING_UPDATE"
>
> If the code is dependent on recognizing names to know what it's doing,
> then I'd say you have a fundamentally broken approach.  Consider adding
> a flag column to pg_rewrite to distinguish these rules, instead.
>

Actually the code delete implicit rules based on a field added to
pg_rewrite but that catalog has a unique index on ev_class, rulename:
"pg_rewrite_rel_rulename_index" UNIQUE, btree (ev_class, rulename)

i guess bernd's comment is about this index giving an error if we try
to insert the new rule with the same name on the same event...

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook

--On Donnerstag, August 24, 2006 11:00:45 -0400 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

> If the code is dependent on recognizing names to know what it's doing,
> then I'd say you have a fundamentally broken approach.  Consider adding
> a flag column to pg_rewrite to distinguish these rules, instead.

This is the approach the code already follows (it uses an additional
ev_kind column which distinguishes rules between implicit rules with
no, local or cascaded check option and explicit ones).

Turns out that i was thinking too difficult when looking at the code which
drops implicit rules....sorry for the noise.

--
  Thanks

                    Bernd

--On Donnerstag, August 24, 2006 11:02:43 -0500 Jaime Casanova
<systemguards@gmail.com> wrote:

> Actually the code delete implicit rules based on a field added to
> pg_rewrite but that catalog has a unique index on ev_class, rulename:
> "pg_rewrite_rel_rulename_index" UNIQUE, btree (ev_class, rulename)
>
> i guess bernd's comment is about this index giving an error if we try
> to insert the new rule with the same name on the same event...

No, this wasn't the problem, since we are going to drop any implicit
rule that collides with an user defined one (however, this approach is
discussable, but nobody has put his comments on this yet and i think this
is important for backwards compatibility). I don't think we need ev_kind in
the
index at all, in my opinion implicit and user defined rules of the same
event
shouldn't live together (_RETURN rules are marked as implicit ones now, too)

--
  Thanks

                    Bernd