Re: [HACKERS] updatable views and default values
On Sat, Sep 02, 2006 at 06:22:49PM -0500, Jim C. Nasby wrote: > On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote: > > For backwards compatibility we should probably say that this > > automatic lifting of base-table defaults happens only if the > > INSERT rule is implicitly generated ... if you write a manual > > INSERT rule you need manual defaults too. Or should "propagate > > default values" become an explicit attribute of ON INSERT rules? > > ISTM that least surprise dictates that inserting into a view uses > the base table default unless you specifically override them. +1 :) Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] updatable views and default values
On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote: > For backwards compatibility we should probably say that this automatic > lifting of base-table defaults happens only if the INSERT rule is > implicitly generated ... if you write a manual INSERT rule you need > manual defaults too. Or should "propagate default values" become an > explicit attribute of ON INSERT rules? ISTM that least surprise dictates that inserting into a view uses the base table default unless you specifically override them. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] 512.569.9461 (cell) http://jim.nasby.net ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] updatable views and default values
"Jaime Casanova" <[EMAIL PROTECTED]> writes: > now that you're reviewing the updatable view patch, i think we must > decide what you're position will be about if the updatable view should > inherit the base table default values... or if we want to create > default values for every view if we want they match with the base > table ones... (fwiw, informix does the former) I'm inclined to agree that if we create an automatic INSERT rule for a view, we ought to automatically copy the base table's defaults up to the view as well. Otherwise the user will certainly want to do that by hand, and the whole point of this feature is to eliminate the need to do obvious things by hand. I think that this would require adding a flag to pg_attrdef entries to show whether they were created implicitly or not, so that pg_dump would know not to dump them. But wait, what if the user does ALTER SET DEFAULT on the base table --- shouldn't that then propagate to the view? Perhaps it would be better if the implementation didn't explicitly store a default expression attached to the view, but were willing to "drill down" to the base table and grab its default. You could still override that by explicitly attaching a different default to the view, but 90% of the time this would be the right thing. For backwards compatibility we should probably say that this automatic lifting of base-table defaults happens only if the INSERT rule is implicitly generated ... if you write a manual INSERT rule you need manual defaults too. Or should "propagate default values" become an explicit attribute of ON INSERT rules? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] updatable views and default values
Hi, now that you're reviewing the updatable view patch, i think we must decide what you're position will be about if the updatable view should inherit the base table default values... or if we want to create default values for every view if we want they match with the base table ones... (fwiw, informix does the former) now the problems... i had a hack in the code to do that but it gives an error now because some refactoring of the code when the multiple values for insert patch was applied... the hack was inside the build_column_default() function and the problem seems to be because we are calling that function from rewriteValuesRTE(), and idea is to put a flag in build_column_default()'s arguments and try to get the base table's default only when that flag is set... but bernd and alvaro's advice was to get your opinions before wasting time coding something that could be rejected... so, opinions? ;) -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster