Re: Rule recompilation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rule recompilation
Date: 2001-07-12 18:50:38
Message-ID: 11596.994963838@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> There is of course a difference between the original
> CREATE RULE/VIEW statement and the string stored here. This
> is because we cannot rely on the actual query buffer but have
> to parseback the parsetree like done by the utility functions
> used for pg_rules.

Did you see my comments about extending the parser to make it possible
to extract the appropriate part of the query buffer? This would allow
us to get rid of the reverse-lister (ruleutils.c) entirely, not to
mention readfuncs.c (but we'd still want outfuncs.c for debugging, I
suppose).

> Anyway, what's the preferred syntax for triggering the rule
> recompilation? I thought about
> ALTER RULE {rulename|ALL} RECOMPILE;
> Where ALL triggers only those rules where the user actually
> has RULE access right on a relation.

The proposed definition of ALL seems completely off-base. If I have
changed my table foo, which is referenced by a rule attached to
Joe's table bar, I would like to be able to force recompilation of
Joe's rule. If I can't do that, a RECOMPILE command is useless.
I might as well just restart my backend.

BTW, a RECOMPILE command that affects only the current backend is pretty
useless anyway. How are you going to propagate the recompile request to
other backends?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-07-12 18:55:42 Re: Rule recompilation
Previous Message Mikheev, Vadim 2001-07-12 18:48:27 RE: Re: Strangeness in xid allocation / snapshot setup