Re: [HACKERS] Delaying insertion of default values

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Jan Wieck <jwieck(at)debis(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Delaying insertion of default values
Date: 1999-07-08 10:27:49
Message-ID: 37847D25.EDE98AB4@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:
>
> Vadim wrote:
>
> > ALTER TABLE could (or should?) re-compile table' rules...
>
> Rules should be recompilable for various reasons. DROP/CREATE
> of objects (relations, functions etc.) referenced in rules
> changes their OID and needs recompilation too.

Yes. And the same is true for stored procedures when we'll
get them.

> > > rule mechanism. Unless I hear objections, I will do that while I am
> > > cleaning up INSERT processing for the INSERT ... SELECT ... GROUP BY bug.
> >
> > No objections -:).
>
> This would be obsolete when having the above recompilation
> implemented. I'll add a support function that takes an OID
> which should be called at any DROP
> TABLE/VIEW/FUNCTION/OPERATOR etc. which will cause rule
> recompilation on the next usage of the relation.

Agreed. I didn't object but of course I more like general solution
- a way to invalidate stored rules/procedures/etc and re-compilate
them when need.

BTW, what's your plan for RI constraints, Jan?
Did you see my letter about statement level triggers?
If I'll get WAL implemented then it could be used for RI.
In any case I believe that statement level triggers
are very nice thing and they are better for RI than
rules.

Vadim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nuchanach Klinjun 1999-07-08 10:59:03 upgrade problem
Previous Message Jan Wieck 1999-07-08 10:11:51 Arbitrary tuple size