Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I'm rewriting several parts of the patch, and have a question. Can I > > assume that there is only one rule on the CMD_SELECT event, for any > > given view? > > Yeah. See the restrictions enforced by DefineQueryRewrite() for > details. There's also a unique index on pg_rewrite that would > have answered $SUBJECT for you ;-)
Doh -- I actually had even noticed there was a syscache for it. But actually, I wanted to know if there can be more than one rule for the CMD_SELECT event, and I see this is enforced in the code rather than restrictions on the catalog. Another question. The patch does a lot of scanning of the range table searching for specific aliases for things -- usually for *NEW* or *OLD*, but also to get the entry for the view we are modifying, etc. This seems pretty fragile -- it breaks if I create a table named *OLD*, for example. Is this acceptable? alvherre=# create table "*OLD*" (a int); CREATE TABLE alvherre=# create view aaa as select * from "*OLD*"; ERROR: could not open relation with OID 0 On the other hand it doesn't break CVS tip at all, i.e. I can perfectly create the view and it works. (I can even call it "*NEW*"). Is this a showstopper? I don't see any other way to walk the RT -- unless I were to change the RTE node representation, I think. Something else that's bothering me is that we mark *NEW* and *OLD* with rtekind RTE_RELATION, but a comment at the top of RangeTblEntry appears to say that they should be marked with RTE_SPECIAL. On the other hand, UpdateRangeTableOfViewParse calls the parser code (addRangeTableEntryForRelation) to insert the RTEs, which forcibly puts RTE_RELATION on them. I tried changing them to RTE_SPECIAL on UpdateRangeTableOfViewParse, but apparently that breaks code somewhere else because I get some regression failures. Do we want to fix that other code, so that *OLD* and *NEW* can always be marked RTE_SPECIAL? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
