From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-bugs <pgsql-bugs@postgresql.org>
Subject: Re: CREATE CAST allows creation of binary-coercible cast to range over domain
Date: Tue, 20 Aug 2024 13:30:39 -0400
Message-ID: <1611527.1724175039@sss.pgh.pa.us> (raw)
In-Reply-To: <1537781.1724165175@sss.pgh.pa.us>
References: <076968e1-0852-40a9-bc0b-117cd3f0e43c@eisentraut.org>
<1537781.1724165175@sss.pgh.pa.us>
I wrote:
> I think it's an oversight that we allow binary-coercible casts
> involving range types at all. There are no other nesting cases to
> worry about, because CreateCast already rejects binary-coercible casts
> applied to composites and arrays, explaining
> * We know that composite, enum and array types are never binary-
> * compatible with each other. They all have OIDs embedded in them.
> But range types also embed their own OID, so I don't see why that
> concern doesn't apply to them.
In short, more or less as attached. (I didn't bother with a
regression test, since none of the adjacent error checks are
covered either.)
I'm unsure whether to back-patch this. If somebody were using
such a cast today, it might seem to mostly work, as long as the
two kinds of ranges had the same behavior. So they might not
appreciate us breaking it in a minor release. Maybe we should
put this into 17 but not further back.
regards, tom lane
Attachments:reject-binary-coercions-on-ranges.patch (text/x-diff, 1.9K) downloaddiff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.cindex 6593fd7d81..149642ab1b 100644--- a/src/backend/commands/functioncmds.c+++ b/src/backend/commands/functioncmds.c@@ -1689,13 +1689,18 @@ CreateCast(CreateCastStmt *stmt)
errmsg("source and target data types are not physically compatible")));
/*
- * We know that composite, enum and array types are never binary-- * compatible with each other. They all have OIDs embedded in them.+ * We know that composite, array, range and enum types are never+ * binary-compatible with each other. They all have OIDs embedded in+ * them.
*
* Theoretically you could build a user-defined base type that is
- * binary-compatible with a composite, enum, or array type. But we- * disallow that too, as in practice such a cast is surely a mistake.- * You can always work around that by writing a cast function.+ * binary-compatible with such a type. But we disallow that too, as+ * in practice such a cast is surely a mistake. You can always work+ * around that by writing a cast function.+ *+ * NOTE: if we didn't exclude every kind of container type for this+ * reason, we'd likely need to recursively apply all of these same+ * checks to the contained type(s).
*/
if (sourcetyptype == TYPTYPE_COMPOSITE ||
targettyptype == TYPTYPE_COMPOSITE)
@@ -1703,6 +1708,14 @@ CreateCast(CreateCastStmt *stmt)
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("composite data types are not binary-compatible")));
+ if (sourcetyptype == TYPTYPE_RANGE ||+ targettyptype == TYPTYPE_RANGE ||+ sourcetyptype == TYPTYPE_MULTIRANGE ||+ targettyptype == TYPTYPE_MULTIRANGE)+ ereport(ERROR,+ (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),+ errmsg("range data types are not binary-compatible")));+
if (sourcetyptype == TYPTYPE_ENUM ||
targettyptype == TYPTYPE_ENUM)
ereport(ERROR,
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, peter@eisentraut.org
Subject: Re: CREATE CAST allows creation of binary-coercible cast to range over domain
In-Reply-To: <1611527.1724175039@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