From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
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-15 18:17:57 |
Message-ID: | 3153441.1644949077@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Delaney, Ed" <Ed(dot)Delaney(at)ellucian(dot)com> writes:
> I could not find a reference to this change in the release notes, but since it is a breaking change, perhaps it should be noted?
The 2021-11-11 release notes all say
* Don't discard a cast to the same type with unspecified type modifier (Tom Lane)
For example, if column f1 is of type numeric(18,3), the parser used to
simply discard a cast like f1::numeric, on the grounds that it would
have no run-time effect. That's true, but the exposed type of the
expression should still be considered to be plain numeric, not
numeric(18,3). This is important for correctly resolving the type of
larger constructs, such as recursive UNIONs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-02-15 20:51:47 | Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade |
Previous Message | Delaney, Ed | 2022-02-15 18:12:29 | Re: Postgres 13.5 out parameter argument with explicit cast fails with argument is not writable |