On 12.11.24 17:08, Peter Eisentraut wrote:
On 11.11.24 12:37, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut
<pe...@eisentraut.org> wrote:
New patch version. I've gone through the whole thread again and looked
at all the feedback and various bug reports and test cases and made sure
they are all addressed in the latest patch version. (I'll send some
separate messages to respond to some individual messages, but I'm
keeping the latest patch here.)
just quickly note the not good error message before you rebase.
src7=# create domain d_fail as int4 constraint cc GENERATED ALWAYS AS
(2) ;
ERROR: unrecognized constraint subtype: 4
src7=# create domain d_fail as int4 constraint cc GENERATED ALWAYS AS
(2) stored;
ERROR: unrecognized constraint subtype: 4
src7=# create domain d_fail as int4 constraint cc GENERATED ALWAYS AS
(2) virtual;
ERROR: unrecognized constraint subtype: 4
reading gram.y, typedef struct Constraint seems cannot distinguish, we
are creating a domain or create table.
I cannot found a way to error out in gram.y.
so we have to error out at DefineDomain.
This appears to be a very old problem independent of this patch. I'll
take a look at fixing it.
Here is a patch.
I'm on the fence about taking out the default case. It does catch the
missing enum values, and I suppose if the struct arrives in
DefineDomain() with a corrupted contype value that is none of the enum
values, then we'd just do nothing with it. Maybe go ahead with this,
but for backpatching leave the default case in place?
From 09f9484f0d2990b4b9be8d2a8b907c134d6d5ee7 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pe...@eisentraut.org>
Date: Thu, 28 Nov 2024 10:23:26 +0100
Subject: [PATCH] Fix handling of CREATE DOMAIN with GENERATED constraint
syntax
Stuff like
CREATE DOMAIN foo AS int CONSTRAINT cc GENERATED ALWAYS AS (2) STORED
is not supported for domains, but the parser allows it, because it's
the same syntax as for table constraints. But CreateDomain() did not
explicitly handle all ConstrType values, so the above would get an
internal error like
ERROR: unrecognized constraint subtype: 4
Fix that by providing a user-facing error message for all ConstrType
values. Also, remove the switch default case, so future additions to
ConstrType are caught.
Reported-by: Jian He <jian.universal...@gmail.com>
Discussion:
https://www.postgresql.org/message-id/CACJufxF8fmM=dbm4pdfuv_nkgz2-no0k4yifhrf3-rjxtwj...@mail.gmail.com
---
src/backend/commands/typecmds.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/backend/commands/typecmds.c b/src/backend/commands/typecmds.c
index 859e2191f08..130741e777e 100644
--- a/src/backend/commands/typecmds.c
+++ b/src/backend/commands/typecmds.c
@@ -1011,10 +1011,14 @@ DefineDomain(CreateDomainStmt *stmt)
errmsg("specifying constraint
deferrability not supported for domains")));
break;
- default:
- elog(ERROR, "unrecognized constraint subtype:
%d",
- (int) constr->contype);
+ case CONSTR_GENERATED:
+ case CONSTR_IDENTITY:
+ ereport(ERROR,
+
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("specifying GENERATED
not supported for domains")));
break;
+
+ /* no default, to let compiler warn about
missing case */
}
}
--
2.47.0
