Re: In RULEs, INSERT does not use DEFAULTs
От | Jaime Casanova |
---|---|
Тема | Re: In RULEs, INSERT does not use DEFAULTs |
Дата | |
Msg-id | c2d9e70e05061411555d881235@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: In RULEs, INSERT does not use DEFAULTs (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: