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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: teg@redhat.com (Trond Eivind Glomsrød)
Дата:
Сообщение: Re: To be 7.1.3 or not to be 7.1.3?
Следующее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: RE: Portal destination issue: binary vs normal cursors