Thread: 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
"Jaime Casanova" <systemguards@gmail.com> 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
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 jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
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 <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!