Re: A problem with dump/restore of views containing whole row references - Mailing list pgsql-hackers

From Abbas Butt
Subject Re: A problem with dump/restore of views containing whole row references
Date
Msg-id CALtH27e4mJoyT2qWm-UaV6oZbuv1S8M1iS593rhaivYzqPFTCg@mail.gmail.com
Whole thread Raw
In response to Re: A problem with dump/restore of views containing whole row references  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: A problem with dump/restore of views containing whole row references  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers


On Fri, Apr 27, 2012 at 6:25 PM, Andrew Dunstan <andrew@dunslane.net> wrote:


On 04/27/2012 08:25 AM, Abbas Butt wrote:

The notation "relation.*" represents a whole-row reference.
While parsing a whole-row reference is transformed into a Var with varno set to the correct range table entry,
and varattno == 0 to signal that it references the whole tuple. (For reference see comments of function makeWholeRowVar)
While deparsing we need to take care of this case.
The attached patch provides deparsing of a whole-row reference.
A whole row reference will be deparsed either into alias.*::relation or relation.*::relation depending on alias


I agree there's a bug, although it's easily worked around: in the case of your example:

  CREATE VIEW v2 AS
       SELECT p AS price FROM price p;

would do the trick.

However, is this a change we really want to make?:

  pg_get_triggerdef
  ---------------------------------------------------------------------------------------------------------------------------------------------------------------
  - CREATE TRIGGER modified_any BEFORE UPDATE OF a ON main_table FOR EACH ROW WHEN (old.* IS DISTINCT FROM new.*) EXECUTE PROCEDURE trigger_func('modified_any')
  +                                                                                  pg_get_triggerdef
  +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  + CREATE TRIGGER modified_any BEFORE UPDATE OF a ON main_table FOR EACH ROW WHEN (old.*::main_table IS DISTINCT FROM new.*::main_table) EXECUTE PROCEDURE trigger_func('modified_any')


Maybe we need to be a bit more selective about when the cast is supplied. It's not adding any extra disambiguation (or clarity) here.

I ran the regression and found that my patch is causing a diff in the trigger test case, thats why I changed the expected output of the test case accordingly. This is a side effect of the change I did to fix the bug.
 

cheers

andrew




--
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: enable_indexonly
Next
From: Andrew Dunstan
Date:
Subject: Re: A problem with dump/restore of views containing whole row references