Re: Trying to understand pg_get_expr()

Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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