From: Tom Lane <tgl@sss.pgh.pa.us>
To: Delaney, Ed <Ed.Delaney@ellucian.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Postgres 13.5 out parameter argument with explicit cast fails with argument is not writable
Date: Tue, 15 Feb 2022 13:17:57 -0500
Message-ID: <3153441.1644949077@sss.pgh.pa.us> (raw)
In-Reply-To: <DM8PR02MB7957E9EB0AF94B614520989EF1349@DM8PR02MB7957.namprd02.prod.outlook.com>
References: <DM8PR02MB79575CE6CE819DB8C424CCABF1339@DM8PR02MB7957.namprd02.prod.outlook.com>
<2959722.1644881309@sss.pgh.pa.us>
<DM8PR02MB7957E9EB0AF94B614520989EF1349@DM8PR02MB7957.namprd02.prod.outlook.com>
"Delaney, Ed" <Ed.Delaney@ellucian.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, Ed.Delaney@ellucian.com, pgsql-bugs@lists.postgresql.org
Subject: Re: Postgres 13.5 out parameter argument with explicit cast fails with argument is not writable
In-Reply-To: <3153441.1644949077@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox