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

From Jaime Casanova
Subject Re: In RULEs, INSERT does not use DEFAULTs
Date
Msg-id c2d9e70e05061411555d881235@mail.gmail.com
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 6/12/05, Tom Lane <tgl@sss.pgh.pa.us> 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.
>
> 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 discarded the idea because i couldn't fight with the polymorphic
function to return the correct value in any case.

But i successfully found that hacking rewriteHandler.c can do the
trick. I am using that in updateable views project.

> Another possibility is a command along the lines of
>     ALTER view ALTER col LINK DEFAULT TO othertable.col;
> (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.
>

That's sounds like a good idea too

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)


pgsql-hackers by date:

Previous
From: "Jonah H. Harris"
Date:
Subject: Re: User Quota Implementation
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Unicode characters above 0x10000 #2