>> test=# CREATE VIEW v3 AS SELECT count(*) FROM v1;
>> CREATE VIEW
>> test=# BEGIN;
>> BEGIN
>> test=# LOCK TABLE v3;
>> ERROR: cannot lock view "v3"
>> DETAIL: Views that return aggregate functions are not automatically updatable.
>
> It would be nice if the message would be something like:
>
> DETAIL: Views that return aggregate functions are not lockable
>
>> test=# END;
>> ROLLBACK
>>
>> test=# CREATE FUNCTION fnc() RETURNS trigger AS $$ BEGIN RETURN NEW; END; $$ LANGUAGE plpgsql;
>> CREATE FUNCTION
>> test=# CREATE TRIGGER trg INSTEAD OF INSERT ON v1 FOR EACH ROW EXECUTE PROCEDURE fnc();
>> CREATE TRIGGER
>> test=# BEGIN;
>> BEGIN
>> test=# LOCK TABLE v1;
>> ERROR: cannot lock view "v1"
>> DETAIL: views that have an INSTEAD OF trigger are not lockable
>> test=# END;
>> ROLLBACK
>
> I wonder if we should lock tables in a subquery as well. For example,
>
> create view v1 as select * from t1 where i in (select i from t2);
>
> In this case should we lock t2 as well?
Current the patch ignores t2 in the case above.
So we have options below:
- Leave as it is (ignore tables appearing in a subquery)
- Lock all tables including in a subquery
- Check subquery in the view definition. If there are some tables involved, emit an error and abort.
The first one might be different from what users expect. There may be
a risk that the second one could cause deadlock. So it seems the third
one seems to be the safest IMO.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers