RE: PL/pgSQL bug?
От | Tatsuo Ishii |
---|---|
Тема | RE: PL/pgSQL bug? |
Дата | |
Msg-id | 20010813100734I.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | RE: PL/pgSQL bug? ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: PL/pgSQL bug?
|
Список | pgsql-hackers |
> > One way to make the results equivalent is to compute a new QuerySnapshot > > for each SPI query. Quite aside from the cost of doing so, I do not > > think it makes sense, considering that the previous QuerySnapshot must > > be restored when we return from the function. Do we really want > > functions to see transaction status different from what's seen outside > > the function call? > > Yes I do. Me too. Current behavior of procedural languages seem hard to understand for users. BTW, why must we restore the previous QuerySnapshot? We already break the rule (if it's a rule). For example, COPY TO calls SetQuerySnapshot (see tcop/utility.c). So, below produces "ERROR: More than one tuple returned by a subselect used as an expression": DROP TABLE t1; CREATE TABLE t1 (i INT PRIMARY KEY); DROP FUNCTION myftest(INT); CREATE FUNCTION myftest(INT) RETURNS INT AS ' UPDATE t1 SET i = 1 WHERE i = 1; SELECT i FROM t1 WHERE i = (SELECT i FROM t1 WHERE i = 1);'LANGUAGE 'sql'; while below does not throw an error: DROP TABLE t1; CREATE TABLE t1 (i INT PRIMARY KEY); DROP FUNCTION myftest(INT); CREATE FUNCTION myftest(INT) RETURNS INT AS ' UPDATE t1 SET i = 1 WHERE i = 1; COPY t1 TO ''/tmp/t1.data''; SELECT i FROM t1 WHERE i = (SELECT i FROM t1 WHERE i =1);'LANGUAGE 'sql';
В списке pgsql-hackers по дате отправления: