On Wed, Feb 10, 2016 at 9:47 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-02-10 10:53:28 +0000, gsv371@ukr.net wrote:
> > PostgreSQL 9.5:
> > 1.
> > ALTER TABLE schedule ADD CONSTRAINT schedule_fact_quant_val CHECK
> > (fact_quant BETWEEN 0 AND 23.59 AND (fact_quant - trunc(fact_quant)) <
> > 0.6);
> > result (pg_constraint.consrc): "(((fact_quant >=3D (0)::numeric) AND
> > (fact_quant <=3D 23.59)) AND ((fact_quant - trunc(fact_quant)) < 0.6))"
> > 2.
> > ALTER TABLE schedule ADD CONSTRAINT schedule_fact_quant_val CHECK
> > (((fact_quant >=3D (0)::numeric) AND (fact_quant <=3D 23.59)) AND
> ((fact_quant -
> > trunc(fact_quant)) < 0.6));
> > result (pg_constraint.consrc): "((fact_quant >=3D (0)::numeric) AND
> > (fact_quant <=3D 23.59) AND ((fact_quant - trunc(fact_quant)) < 0.6))"
> > ----------------------------------
> > PostgreSQL 9.4 - identical results!
>
> Why do you consider that a bug?
>
>
=E2=80=8BProbably because of this 9.5 release note item:
"""
=E2=80=8B
Version 9.5 contains a number of changes that may affect compatibility
with previous releases. Observe the following incompatibilities:
Adjust operator precedence to match the SQL standard (Tom Lane)
The precedence of <=3D, >=3D and <> has been reduced to match that of <, > =
and
=3D. The precedence of IS tests (e.g., x IS NULL) has been reduced to be ju=
st
below these six comparison operators. Also, multi-keyword operators
beginning with NOT now have the precedence of their base operator (for
example, NOT BETWEEN now has the same precedence as BETWEEN) whereas before
they had inconsistent precedence, behaving like NOT with respect to their
left operand but like their base operator with respect to their right
operand. The new configuration parameter operator_precedence_warning can be
enabled to warn about queries in which these precedence changes result in
different parsing choices.
=E2=80=8B"""
David J.
