Re: pg_type defaults - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_type defaults
Date
Msg-id 1733.1014231199@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_type defaults  ("Rod Taylor" <rbt@zort.ca>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: "Rod Taylor"
Date:
Subject: Re: Trouble with pg_dumpall import with 7.2
Next
From: Tom Lane
Date:
Subject: Re: Trouble with pg_dumpall import with 7.2