Hiroshi Inoue wrote:
> Tom Lane wrote:
> >
> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > Of cource it is nice to have a complete solution
> > > immediately but it doesn't seem easy. My patch is
> > > only a makeshift solution but fixes the most
> > > siginificant case(typical updatable views).
> >
> > I would like to devise a complete solution *before* we consider
> > installing makeshift solutions (which will institutionalize wrong
> > behavior).
> >
> > There seems to be some feeling here that in the presence of rewrites
> > you only want to know that "something happened". Are you suggesting
> > that the returned tuple count should be the sum of all counts from
> > insert, update, and delete actions that happened as a result of the
> > query? We could certainly implement that, but it does not seem like
> > a good idea to me.
>
> What should the backends return for complicated rewrites ?
> And how should/could clients handle the results ?
> It doesn't seem easy to me and it seems a flaw of rule
> system. Honestly I don't think that the psqlodbc driver
> can guarantee to handle such cases properly.
> However both Ron's case and Michael's one are ordinary
> updatable views. If we can't handle the case properly,
> we could never recommend users to use (updatable) views.
The fact that our rule system is that powerful that you can
have multi-action rules is a flaw ... awe.
Do you think that if a trigger suppresses your original
insert, but instead does 2 inserts somewhere else and another
update and delete here and there, then 0 is the correct
answer to the client? Well, that's what happens now, so it
should irritate your client in exactly the same way. So not
only our rule system, but our trigger system has a flaw too.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 3: 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
