Re: Can I assume there's only one _RETURN rule?

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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