| From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
|---|---|
| To: | Inoue(at)tpf(dot)co(dot)jp |
| Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, JanWieck(at)Yahoo(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | RE: PL/pgSQL bug? |
| Date: | 2001-08-13 01:07:34 |
| Message-ID: | 20010813100734I.t-ishii@sra.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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';
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2001-08-13 01:48:49 | RE: Portal destination issue: binary vs normal cursors |
| Previous Message | Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= | 2001-08-13 01:03:43 | Re: To be 7.1.3 or not to be 7.1.3? |