From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rule recompilation |
Date: | 2001-07-12 20:05:05 |
Message-ID: | Pine.BSO.4.10.10107121604390.4070-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 12 Jul 2001, Peter Eisentraut wrote:
> Jan Wieck writes:
>
> > For most objects, there is no such "recompile" possible - at
> > least not without storing alot more information than now.
> > Create a function and based on that an operator. Then you
> > drop the function and create another one. Hmmm, pg_operator
> > doesn't have the function name and argument types, it only
> > knows the old functions oid. How do you find the new function
> > from here?
>
> In these cases it'd be a lot simpler (and SQL-comforming) to implement the
> DROP THING ... { RESTRICT | CASCADE } options. This would probably catch
> most honest user errors more cleanly than trying to automatically
> recompile things that perhaps aren't even meant to fit together any
> longer.
Yes, I absolutely agree, and that's the aim of what I'm suggesting...
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2001-07-12 21:07:24 | Re: Rule recompilation |
Previous Message | Bruce Momjian | 2001-07-12 19:53:55 | Re: Re: [GENERAL] Vacuum and Transactions |