Adrian Klaver <adrian.klaver@aklaver.com> writes:
> adrelid | pg_typeof | pg_get_expr
> --------------+-----------+---------------------------
> default_test | text | 'test'::character varying
> default_test | text | 0
> Why is the second case not?:
> '0'::integer
PG's parser automatically attributes type integer to an unadorned
integer literal, so no cast is necessary there, and pg_get_expr
doesn't add one. But an unadorned string like 'test' does not
have a determinate type (well, it has type "unknown", but that
is an implementation artifact). We emit a cast construct to show
what type the constant was resolved as.
The bigger picture here is that pg_get_expr relies on the same
code that is used for purposes like dumping views. We want the
output to be such that subexpressions of a view will certainly
be parsed as the same type they were interpreted as before.
regards, tom lane
