Re: pg_type defaults

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

In response to

Responses

Browse pgsql-hackers by date

  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