Re: In RULEs, INSERT does not use DEFAULTs - Mailing list pgsql-hackers

From David Fetter
Subject Re: In RULEs, INSERT does not use DEFAULTs
Date
Msg-id 20050613051302.GE18728@fetter.org
Whole thread Raw
In response to Re: In RULEs, INSERT does not use DEFAULTs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jun 12, 2005 at 11:48:29PM -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > I believe this isn't just my problem.  Without access to a the
> > underlying column's DEFAULT, how can people implement the automated
> > WRITEable VIEWs?
> 
> That's a reasonable question, but translating "insert null" to "insert
> the default" is not a reasonable answer.

Right.  My mistake.

> There was some speculation just a couple days ago about inventing a
> function that would compute the default associated with some other
> table's column, but it's not clear how to make that work (in
> particular, how to declare the result type of such a function).

I was looking into polymorphic functions for this.  At least in
PL/PgSQL (which isn't a general solution, but I was looking for my own
solution) there is a way to get the return type based on the input
types.

> Another possibility is a command along the lines of
>     ALTER view ALTER col LINK DEFAULT TO othertable.col;

I still think that something like this (i.e. the VIEWs column has the
same default as its underlying base TABLE or VIEW, where there is one)
should be the default behavior.  Principle of Least Astonishiment.

> (syntax open to argument of course) which accomplishes the
> same thing without having to figure a way to avoid the constraints
> of a specific function result type.

It'd be nice to have one of these :)

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: In RULEs, INSERT does not use DEFAULTs
Next
From: Greg Stark
Date:
Subject: Re: The Contrib Roundup (long)