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.vondra@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
