From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_type defaults |
Date: | 2002-02-20 17:10:38 |
Message-ID: | 05c401c1ba31$85ae48c0$8001a8c0@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)megazone23(dot)bigpanda(dot)com>
To: "Rod Taylor" <rbt(at)zort(dot)ca>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)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.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2002-02-20 17:13:03 | Re: [ODBC] UTF-8 data migration problem in Postgresql 7.2 |
Previous Message | Tom Lane | 2002-02-20 17:04:29 | Re: [ODBC] UTF-8 data migration problem in Postgresql 7.2 |