Alvaro Herrera <alvherre@commandprompt.com> writes:
> 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?
The rule stuff already depends on "*NEW*" and "*OLD*" being unique as
table aliases, though IIRC not as actual table names. Maybe it'd be
worth adding something to reject SELECT ... FROM foo "*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.
The *NEW*/*OLD* stuff is pretty ugly, but it was there already for
many years, and now seems not the time to fix it.
However, I'm not sure you need to be depending on those textual names.
IIRC much of that code depends on rangetable indexes, instead --- look
for references to PRS2_OLD_VARNO and PRS2_NEW_VARNO. That's
considerably safer because the rule creation code can actually guarantee
what's in those rtable positions.
> 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.
I think they have to be RTE_RELATION because they serve in part as OID
references to the table-having-the-rule for dependency purposes. Again,
this is stuff to be cleaning up during development, not three weeks
after feature freeze.
regards, tom lane
