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.
>
>
>
