From: | Jaime Casanova <systemguards(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: In RULEs, INSERT does not use DEFAULTs |
Date: | 2005-06-14 18:55:14 |
Message-ID: | c2d9e70e05061411555d881235@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/12/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Fetter <david(at)fetter(dot)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 ;)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-06-14 23:47:40 | pgsql: Add BETWEEN SYMMETRIC. |
Previous Message | Jonah H. Harris | 2005-06-14 17:39:06 | Re: User Quota Implementation |