Where are we on this feature? ---------------------------------------------------------------------------
Bernd Helmle wrote: > --On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane <[EMAIL PROTECTED]> > wrote: > > > Bernd Helmle <[EMAIL PROTECTED]> writes: > >> [ latest views patch ] > > > > This is the first time I've actually looked at this patch, and I am > > dismayed. viewUpdate.c looks like nothing so much as a large program > > with a small program struggling to get out. What is all the stuff about > > handling multiple base rels? SQL92, at least, does not say that a join > > is updatable, and AFAICT this patch is rejecting that too ... though > > it's hard to tell with the conditions for allowing the join to be > > updatable scattered through a lot of different functions. And some of > > the code seems to be expecting multiple implicit rules and other parts > > not. I get the impression that a lot of this code is left over from a > > more ambitious first draft and ought to be removed in the name of > > readability/maintainability. > > > > I not sure what parts of the code you are refering to exactly, but I admit > that > there are code parts that could deal with multiple base relations and > rules. > get_base_base_relation() is an example, it is used to create lookup tables > for reversed columns so we could break them down to the correct position in > their base tables. Restricting that to only one base relation wouldn't make > any > difference. Furthermore, SQL99 allows at least updatable views with joined > relations which preserve their keys in the view definition. So i don't > think it's that > bad to leave parts of the code that way for future improvements. > > > I'm unclear as to why you've got DO INSTEAD NOTHING rules in there --- > > the spec says that a WITH CHECK OPTION violation results in an error, > > not in nothing happening, so it doesn't seem to me that we should need > > any NOTHING rules to implement the spec. It would probably help if > > Well, instead of something like > > "ERROR: cannot insert into a view > HINT: You need an unconditional ON INSERT DO INSTEAD rule." > > you will get > > "ERROR: view update commands violates rule condition" > > with the correct error code set, because the view update check function is > fired before. > The first one isn't very useful for someone who simply wants to insert data > into the > view which isn't allowed to get in. You never get the view update check > function fired > without the DO INSTEAD rule applied to a view created with a check option. > > > there were some header documentation that explained exactly how the > > module intends to transform a SELECT to create the various action rules. > > > > I agree with you, maybe it's a good to add a README to src/backend/rewrite? > > > The pg_dump changes seem pretty odd too. Why wouldn't you just > > ignore implicit rules during a dump, expecting the system to > > regenerate them when the view is reloaded? > > Uhm, you're right. It's easier to exclude them in the SELECT query directly > instead > of selecting them, iterating over and filter them out. I'll fix that. > (Looks like this is a > "cannot see the wood for the trees"-mistake....) > > > -- > Thanks > > Bernd > > ---------------------------(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 -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
