Re: Trying to understand pg_get_expr()

[Marcos Pegoraro]

Em ter., 17 de mar. de 2026 às 18:04, Tom Lane <t...@sss.pgh.pa.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