Re: Trying to understand pg_get_expr()

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