Re: pg_type defaults

"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