Re: A problem with dump/restore of views containing whole row references

Поиск
Список
Период
Сортировка
От Abbas Butt
Тема Re: A problem with dump/restore of views containing whole row references
Дата
Msg-id CALtH27e4mJoyT2qWm-UaV6oZbuv1S8M1iS593rhaivYzqPFTCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A problem with dump/restore of views containing whole row references  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: A problem with dump/restore of views containing whole row references  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: enable_indexonly
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: A problem with dump/restore of views containing whole row references