Re: [HACKERS] [PATCH] Lockable views

Tatsuo Ishii <ishii@sraoss.co.jp>

From: Tatsuo Ishii <ishii@sraoss.co.jp>
To: nagata@sraoss.co.jp
Cc: andres@anarazel.de, ishii@sraoss.co.jp, robertmhaas@gmail.com, thomas.munro@enterprisedb.com, pgsql-hackers@postgresql.org
Date: 2018-04-04T22:53:42Z
Lists: pgsql-hackers
>> > > +typedef struct
>> > > +{
>> > > +	Oid root_reloid;
>> > > +	LOCKMODE lockmode;
>> > > +	bool nowait;
>> > > +	Oid viewowner;
>> > > +	Oid viewoid;
>> > > +} LockViewRecurse_context;
>> > 
>> > Probably wouldn't hurt to pgindent the larger changes in the patch.

Yeah. Also, each struct member needs a comment.

>> > Hm, how can that happen? And if it can happen, why can it only happen
>> > with the root relation?
>> 
>> For example, the following queries cause the infinite recursion of views. 
>> This is detected and the error is raised.
>> 
>>  create table t (i int);
>>  create view v1 as select 1;
>>  create view v2 as select * from v1;
>>  create or replace view v1 as select * from v2;
>>  begin;
>>  lock v1;
>>  abort;
>> 
>> However, I found that the previous patch could not handle the following
>> situation in which the root relation itself doesn't have infinite recursion.
>> 
>>  create view v3 as select * from v1;
>>  begin;
>>  lock v3;
>>  abort;

Shouldn't they be in the regression test?

It's shame that create_view test does not include the cases, but it's
another story.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


Commits

  1. Allow to lock views.