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);
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                      
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

Reply via email to