Re: Queries using rules show no rows modified?

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Michael Alan Dorman <mdorman(at)debian(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Queries using rules show no rows modified?
Date: 2002-05-10 10:19:16
Message-ID: 200205101019.g4AAJGD03410@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> 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.

IMHO the answer should only be a number if the rewritten
querytree list consists of one query of the same command
type. everything else has to lead into "unknown".

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Enke, Michael 2002-05-10 10:27:45 Re: Bug #659: lower()/upper() bug on ->multibyte<- DB
Previous Message Jan Wieck 2002-05-10 10:12:47 Re: the parsing of parameters