Re: [HACKERS] Delaying insertion of default values

Поиск
Список
Период
Сортировка
От Vadim Mikheev
Тема Re: [HACKERS] Delaying insertion of default values
Дата
Msg-id 37847D25.EDE98AB4@krs.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] Delaying insertion of default values  (wieck@debis.com (Jan Wieck))
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] spinlock freeze again
Следующее
От: "D'Arcy" "J.M." Cain
Дата:
Сообщение: More on shared objects problem