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
