Mmm. # I eventually found messages sent to me stashed in unexpcted # place. I felt I was in a void space for these days.. That's # silly!
Thank you for the comment. # Putting aside the appliability(?) of this check.. At Fri, 12 Jul 2019 13:14:57 +0200, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote in <20190712111457.ekkcgx5mpkxl2ooh@development> > On Fri, Jul 12, 2019 at 03:44:58PM +0900, Kyotaro Horiguchi wrote: > >Hello. > > > >As mentioned in the following message: > > > >https://www.postgresql.org/message-id/20190712.150527.145133646.horikyota.ntt%40gmail.com > > > >Mutable function are allowed in check constraint expressions but > >it is not right. The attached is a proposed fix for it including > >regression test. > > > > I think the comment in parse_expr.c is wrong: > > /* > * All SQL value functions are stable so we reject them in check > * constraint expressions. > */ > if (pstate->p_expr_kind == EXPR_KIND_CHECK_CONSTRAINT) > ereport(ERROR, > (errcode(ERRCODE_INVALID_OBJECT_DEFINITION), > errmsg("mutable functions are not allowed in check > constraints"))); > > At first it claims SQL value functions are stable, but then rejects > them > with a message that they're mutable. Isn't Stable mutable? By definition stable functions can return different values with the same input. But the message may be somewhat confusing for unaccostomed users. > Also, the other places use "cannot ..." messages: > > case EXPR_KIND_COLUMN_DEFAULT: > err = _("cannot use column reference in DEFAULT expression"); > break; > > so maybe these new checks should use the same style. It is following to messages like the follows: parse_func.c:2497 | case EXPR_KIND_CHECK_CONSTRAINT: | case EXPR_KIND_DOMAIN_CHECK: | err = _("set-returning functions are not allowed in check constraints"); Should we unify them? "are not allowed in" is used in parse_func.c and parse_agg.c, and "cannot use" is used in parse_expr.c for the same instruction. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
