From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Andrzej Kosmala <ak(at)webproject(dot)pl>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: "ERROR: Query-specified return tuple and actual function |
Date: | 2003-01-13 19:52:25 |
Message-ID: | 4689.1042487545@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Andrzej Kosmala wrote:
>> PostgreSQL 7.3 on Linux
>> After dropping column functions return error message: "ERROR:
>> Query-specified return tuple and actual function return tuple do not match"
> Hmmm, looks like nodeFunctionscan.c:tupledesc_mismatch needs to be
> taught about attisdropped. I'll submit a patch this evening if no one
> else gets to it first.
Actually, I believe I deliberately left it like that because I was
concerned about what would happen in this scenario. I don't think that
changing tupledesc_mismatch to ignore attisdropped columns will make
things work nicely. If a function is expecting to return (a,b,c) and
then you drop b from the table that defines its return type, is the
function likely to magically return (a,c)? I doubt it. Letting the
code get past the mismatch check is likely to result in core dumps.
I had toyed with the notion of forbidding column drop (and maybe column
add too, not sure) whenever a table's rowtype appears as a function
argument or result type; but I'm not sure that's sufficient to protect
against problems ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrzej Kosmala | 2003-01-13 23:21:57 | Re: "ERROR: Query-specified return tuple and actual function |
Previous Message | Joe Conway | 2003-01-13 19:06:12 | Re: "ERROR: Query-specified return tuple and actual function |