Re: Trying to understand pg_get_expr()

Em ter., 17 de mar. de 2026 às 18:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> 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

Thanks Tom

If your fields default to a string, then all them will have to cast back to
its type when calling that function.

CREATE TABLE default_test (
id integer,
fld_1 varchar DEFAULT 'test',
fld_2 integer DEFAULT '150'::text::integer,
fld_3 date DEFAULT '2026/05/01',
fld_4 timestamp DEFAULT '2026/05/01',
fld_5 text DEFAULT 'x',
fld_6 boolean DEFAULT 'on'::text::boolean,
fld_7 int4range DEFAULT '[1,2)',
fld_8 char DEFAULT '1'
);

regards
Marcos