From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Different results in a loop with RECORD vs ROWTYPE... |
Date: | 2003-05-23 03:47:59 |
Message-ID: | 13405.1053661679@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Sean Chittenden <sean(at)chittenden(dot)org> writes:
> CREATE TABLE s.c (
> x BIGINT NOT NULL,
> y BIGINT NOT NULL,
> w INT NOT NULL DEFAULT 1::INT
> );
> DECLARE
> r_c s.c%ROWTYPE; -- RECORD;
> BEGIN
> FOR r_c IN SELECT d.y FROM s.c d WHERE d.x = NEW.x LOOP
> PERFORM s.add_y_to_x(r_c.y,NEW.z);
It seems to me that the rowtype of this SELECT's result is (y bigint).
When you declare r_c as RECORD, it adopts that rowtype, and so the
reference to r_c.y in the PERFORM delivers the value you want. But
when you declare r_c as s.c%ROWTYPE, that is (x bigint, y bigint, w int),
the result of the SELECT's first column is delivered into r_c.x and then
the other two columns are set to null. So r_c.y is null in the PERFORM.
I think this is basically pilot error, though one could certainly argue
that the system ought to be complaining that the SELECT didn't deliver
enough columns to fill the rowtype variable. Any thoughts? Can anyone
report what Oracle's pl/sql does in comparable situations?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Chittenden | 2003-05-23 04:20:36 | Re: Different results in a loop with RECORD vs ROWTYPE... |
Previous Message | Sean Chittenden | 2003-05-23 00:54:17 | Re: Different results in a loop with RECORD vs ROWTYPE... |