From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "Delaney, Ed" <Ed(dot)Delaney(at)ellucian(dot)com> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Postgres 13.5 out parameter argument with explicit cast fails with argument is not writable |
Date: | 2022-02-14 23:24:34 |
Message-ID: | CAKFQuwZ1BcigxzYtW1hBDQ5-7TC363Xq5DGV15QnBU2V5ZejNg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Feb 14, 2022 at 3:50 PM Delaney, Ed <Ed(dot)Delaney(at)ellucian(dot)com> wrote:
> I do not have pg 13.6 installed yet as we just upgraded all of our systems
> from 11 to 13.5 but I suspect it will be the same.
>
>
>
> declare
>
> lv_somestring character varying (4000);
>
> begin
>
> call foo(lv_somestring::character varying); -- note cast
>
>
> While no explicit cast is actually required, we have a very large amount
> of generated code that uses explicit type casting this way.
>
>
>
I'm unsure about the regression but in fact the explicit cast is simply
incorrect conceptually. You are supposed to be supplying a variable to the
call. What you are supplying is a constant. That constant has the same
value as the variable but is not itself a variable and even has a different
type. If you write: SELECT lv_somestring::varchar(1) you will get back the
first character of the max 4,000 character value presently in the variable
lv_somestring. But you will not be changing the value stored in
lv_somestring. Extend that concept to CALL and you can see why the error
you are being shown in v13 is correct.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-14 23:28:29 | Re: Postgres 13.5 out parameter argument with explicit cast fails with argument is not writable |
Previous Message | Delaney, Ed | 2022-02-14 22:50:06 | Postgres 13.5 out parameter argument with explicit cast fails with argument is not writable |