Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait

On Wed, Feb 10, 2016 at 5:07 PM, =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 =D0=
=93=D0=B0=D0=B2=D1=80=D0=B8=D0=BB=D0=B5=D0=BD=D0=BA=D0=BE <gsv371@ukr.net> =
wrote:

> =D0=9E=D1=82 =D0=BA=D0=BE=D0=B3=D0=BE: "David G. Johnston" <david.g.johns=
ton@gmail.com>
> =D0=94=D0=B0=D1=82=D0=B0: 10 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2=
016, 19:01:01
>
> On Wed, Feb 10, 2016 at 9:52 AM, David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>
> 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 =
just
> 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 befo=
re
> 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"""
>
>
> =E2=80=8BTo clarify - the release note probably explains why the 9.4 (wit=
h extra
> parens) and 9.5 (without) constraints behave the same.  It is not a bug i=
n
> the 9.5 version while it could be considered one in 9.4 that has now been
> corrected...  In either case it appears to be working as designed but I
> haven't attempted to figure out exactly =E2=80=8Bhow the changes apply to=
 this
> specific expression.
>
> David J.
>
>
> Hi, just sorry for my english, it's Google translator.
> This is the reason the lack of detailed description of the problems
> discussed in "bug".
> Maybe it's not a bug in the truest sense.
>
> There is a process:
> In the empty base creates the necessary data structure.
> Then, based on the contents of the tables "pg_catalog" obtain and maintai=
n the
> description of this structure (snapshot).
> In the future, comparing the (snapshot) with another (snapshot) received
> from the production database, a decision about the difference between the
> structures and the need to transform the production database.
>
> The essence of the problem :
> Developer creates check constrait according to [1] describe the bug.
> In reference (snapshot) to store the result of [1] describe the bug.
> The production database is missing the check constraint and the decision =
of
> its creation.
> Add instruction is generated from the reference (snapshot) and
> corresponds to [2] describe the bug.
> After this addition, we obtain check constrait which is functionally
> equivalent to the reference, but differs from the description of the
> reference.
> And this in turn causes a re-creation check constrait for each of the
> subsequent verification of the production database structure.
>
>
What are you looking for from us?

The best I can get from the above is you dislike the fact that when the
system dumps a definition is doesn't match the code that was used during
its original creation.  If that is the case I'm not sure what to say...the
system parses and then acts upon the original query to update itself and
then throws away the original.  If asked it can faithfully construct code
that will have the equivalent effect.
=E2=80=8B


=E2=80=8BDavid J.=E2=80=8B