Re: [HACKERS] Delaying insertion of default values
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Delaying insertion of default values |
Дата | |
Msg-id | 199907080059.UAA18379@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Delaying insertion of default values (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> More generally, I wonder whether it is such a good idea for rules to be > stored as parsetrees. For example, I can't drop and recreate a table > mentioned in a rule attached to a different table, because the compiled > rule includes the OIDs of the tables it references. So the compiled > rule will start failing if I do that. (Right now, this causes a core > dump :-( ... apparently someone is assuming that the OID in an RTE will > never be bad ...) > > With rules stored as parsetrees, we need to be very careful about how > much semantic knowledge gets factored into the parsetree before it is > frozen as a rule. (This is another reason for pushing "optimization" > transformations out of the parser and into modules downstream of the > rule rewriter, BTW.) > > Comments? Storing rules as plain text would be too slow, perhaps, > but would it help any to store rules as "raw" parsetrees that haven't > yet gone through analyze.c? All this sounds good, though we have so many TODO items, it seems a little of a reach to be going after this. Seems like a good thing to do as you add that extra phase of query processing. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: