Re: pg_get_constraintdef() doesn't always give an equal constraint

Jeff Davis <pgsql@j-davis.com> writes:
> create table pt(a int, b int, c float8 check (c < '10.1'));
> create table ct(a int, b int, c float8);
> select pg_get_constraintdef(oid) from pg_constraint where conname='pt_c_check';
>          pg_get_constraintdef
> --------------------------------------
>  CHECK ((c < 10.1::double precision))
> (1 row)

> -- copy constraint to "ct" using syntax given above
> alter table ct add constraint pt_c_check CHECK ((c < 10.1::double precision));
> select pg_get_constraintdef(oid) from pg_constraint where conname='pt_c_check';
>           pg_get_constraintdef
> ----------------------------------------
>  CHECK ((c < 10.1::double precision))
>  CHECK ((c < (10.1)::double precision))
> (2 rows)

What's evidently happening here is that ruleutils.c thinks it can dump a
float8 constant using the syntax "10.1::double precision", but the parser
will interpret that as a numeric constant with a separate cast step.

I don't see any simple way around that except to dump using the syntax
    '10.1'::double precision
which is ugly as sin, but perhaps we have no choice.  A longer-term
solution might be to get the parser to interpret
    10.1::double precision
as a float8 literal to start with, but that seems like it could have
unexpected side-effects?  Not sure.

OTOH, you could argue that existing dump files already have the
unquoted-literal syntax so it behooves us to try to get the parser
to read them as they were meant.

A larger issue is that I have a nasty feeling that this isn't the
only place where ruleutils.c output might be read in a way that's
functionally equivalent to the original, but not the exact same
parsetree.

            regards, tom lane