Thread: pg_type defaults

According to the system table documentation
http://developer.postgresql.org/docs/postgres/catalog-pg-type.html the
typdefault information is to be copied from the pg_type value to the
table value when the default specified is NULL or a default is not
specified.

The below shows that it's not to be true.


junk=# update pg_type set typdefault = 3 where typname = 'int2';
UPDATE 1
junk=# create table example (col1 int2);
CREATE
junk=# \d example       Table "example"Column |   Type   | Modifiers
--------+----------+-----------col1   | smallint |






--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.

On Wed, 20 Feb 2002, Rod Taylor wrote:

> According to the system table documentation
> http://developer.postgresql.org/docs/postgres/catalog-pg-type.html the
> typdefault information is to be copied from the pg_type value to the
> table value when the default specified is NULL or a default is not
> specified.
>
> The below shows that it's not to be true.
>
>
> junk=# update pg_type set typdefault = 3 where typname = 'int2';
> UPDATE 1
> junk=# create table example (col1 int2);
> CREATE
> junk=# \d example
>         Table "example"
>  Column |   Type   | Modifiers
> --------+----------+-----------
>  col1   | smallint |

Seems to work for me :)
insert into example default values;
select * from example;
col1
------   3

It doesn't show up in \d, but it is the default. I'd
also say this makes sense/is right since the type's default
is 3 and you don't have a default on the table.

Ahh... I see.  Didn't even consider actually trying an insert.

It breaks pretty hard with anything complex in it, like a function
call, or even a simple cast.

Copies across the statement itself rather than doing the action it
specifies.

So...  leading into domains.  Will I be required to store a binary
parse of the default value and somehow
cause it to be interpreted?

CREATE DOMAIN dom1 int4 DEFAULT 3;

The above works for me.

CREATE DOMAIN dom1 int4 DEFAULT nextval('sequence'::text);

What I store in the typdefault is similar to whats generated for
pg_attrdef.adsrc & pg_attrdef.adbin.

That is, cook the default, confirm it works, and store the output of:
   defaultValue = deparse_expression(expr,       deparse_context_for(stmt->domainname,            InvalidOid),
   false);
 

I had somehow thought it might be reparsing the default.

I guess it needs a defaultbin column to store the binary
representation.  Would it be appropriate to change the first default
directly as a nodetree and have pg_dump coax it back into the source
representation?   Is it necessary to store both representations of the
data even though it's a simple conversion to go from binary to source?

--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Hackers List" <pgsql-hackers@postgresql.org>
Sent: Wednesday, February 20, 2002 11:24 AM
Subject: Re: [HACKERS] pg_type defaults


>
> On Wed, 20 Feb 2002, Rod Taylor wrote:
>
> > According to the system table documentation
> > http://developer.postgresql.org/docs/postgres/catalog-pg-type.html
the
> > typdefault information is to be copied from the pg_type value to
the
> > table value when the default specified is NULL or a default is not
> > specified.
> >
> > The below shows that it's not to be true.
> >
> >
> > junk=# update pg_type set typdefault = 3 where typname = 'int2';
> > UPDATE 1
> > junk=# create table example (col1 int2);
> > CREATE
> > junk=# \d example
> >         Table "example"
> >  Column |   Type   | Modifiers
> > --------+----------+-----------
> >  col1   | smallint |
>
> Seems to work for me :)
> insert into example default values;
> select * from example;
>
>  col1
> ------
>     3
>
> It doesn't show up in \d, but it is the default. I'd
> also say this makes sense/is right since the type's default
> is 3 and you don't have a default on the table.
>
>
>

"Rod Taylor" <rbt@zort.ca> writes:
> It breaks pretty hard with anything complex in it, like a function
> call, or even a simple cast.

It doesn't "break".  The definition of the column is perfectly clear
IMHO: it's the external representation of a literal of the datatype.

> So...  leading into domains.  Will I be required to store a binary
> parse of the default value and somehow
> cause it to be interpreted?

If you want to allow nonconstant defaults, then yes, you'd need to store
an expression tree or some such.

> I guess it needs a defaultbin column to store the binary
> representation.  Would it be appropriate to change the first default
> directly as a nodetree and have pg_dump coax it back into the source
> representation?   Is it necessary to store both representations of the
> data even though it's a simple conversion to go from binary to source?

Although it might seem redundant, I think it may be a good idea to store
both representations.  See past discussions about updating column
default expressions, constraints, etc, when a referenced function or
operator changes.  Sometimes it's better to have the source form,
sometimes it's better to have the parsed form.  We don't currently make
any effort to fix these things when a change breaks them, but
someday someone will take on that project.
        regards, tom lane