Re: Can I assume there's only one _RETURN rule? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Can I assume there's only one _RETURN rule?
Date
Msg-id 20060818023914.GC32181@alvh.no-ip.org
Whole thread Raw
In response to Re: Can I assume there's only one _RETURN rule?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Can I assume there's only one _RETURN rule?
Re: Can I assume there's only one _RETURN rule?
Re: Can I assume there's only one _RETURN rule?
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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


pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: pgstattuple extension for indexes
Next
From: Tom Lane
Date:
Subject: Re: Can I assume there's only one _RETURN rule?