On Sun, 8 Sep 2002 19:50:21 -0300, Steve Howe <[EMAIL PROTECTED]>
wrote:
>Proposal #1 (author: Steve Howe):
>-
>
>PQcmdStatus() ==> Should return the last executed command
#1a
> or the same as the original command
#1b = #2
>PQcmdTuples() ==> sho
> Oh, this is bad news. The problem we have is that rules don't
> distinguish the UPDATE on the underlying tables of the rule from other
> updates that may appear in the query.
>
> If we go with Tom's idea and total just UPDATE's, we will get the right
> answer when there is only one UPDATE in
> > Here are the proposals for solutioning the "Return proper effected
> > tuple count from complex commands [return]" issue as seen on TODO.
> >
> > Any comments ?... This is obviously open to voting and discussion.
>
> We don't have a whole lot of freedom in this; this area is
> covered by th
Peter Eisentraut wrote:
> Steve Howe writes:
>
> > Here are the proposals for solutioning the "Return proper effected
> > tuple count from complex commands [return]" issue as seen on TODO.
> >
> > Any comments ?... This is obviously open to voting and discussion.
>
> We don't have a whole lot of
Hello Peter,
Monday, September 9, 2002, 3:41:41 PM, you wrote:
PE> Steve Howe writes:
>> Here are the proposals for solutioning the "Return proper effected
>> tuple count from complex commands [return]" issue as seen on TODO.
>>
>> Any comments ?... This is obviously open to voting and discussi
Steve Howe writes:
> Here are the proposals for solutioning the "Return proper effected
> tuple count from complex commands [return]" issue as seen on TODO.
>
> Any comments ?... This is obviously open to voting and discussion.
We don't have a whole lot of freedom in this; this area is covered b
> I don't think we should add tuple counts from different commands, i.e.
> adding UPDATE and DELETE counts just yields a totally meaningless
> number.
Agreed.
> I don't think there is any need/desire to add additional API routines to
> handle multiple return values.
Yup.
> Can I get some vo
On Sun, 8 Sep 2002, Steve Howe wrote:
> Here are the proposals for solutioning the "Return proper effected
> tuple count from complex commands [return]" issue as seen on TODO.
>
> Any comments ?... This is obviously open to voting and discussion.
As it seems we're voting, I think Tom's scheme i
Steve Howe wrote:
> BM> We would return 0 for oid and an insert count, just like INSERT INTO ...
> BM> SELECT. How is that weird?
> It's not weird, or as weird as the other proposal which is retrieving
> the last inserted OID number. If we can return some information for
> the client, why not doi
Hello Bruce,
Monday, September 9, 2002, 12:39:20 AM, you wrote:
>> BM> I don't understand this objection.
>> I misunderstood Joe's statement into thinking we wanted to sum the
>> OIDs for all INSERT commands applied :)
>> Please ignore this.
>> But now that I read it again, I would prefer having
Bruce Momjian wrote:
> OK. Do any people have INSTEAD rules where there are not commands
> matching the original query tag? Can anyone think of such a case being
> created?
>
> The only one I can think of is UPDATE implemented as separate INSERT and
> DELETE commands.
>
I could see an UPDATE
Hello Bruce,
Monday, September 9, 2002, 12:36:38 AM, you wrote:
BM> Joe Conway wrote:
>> Sure, but that's why I am in favor of changing the tag. If you did:
>>
>> DELETE FROM fooview WHERE name LIKE 'Joe%';
>>
>> and got:
>>
>> MUTATED 507324 3
>>
>> it would mean that 3 tuples in total were
Steve Howe wrote:
> Hello Bruce,
>
> Monday, September 9, 2002, 12:22:26 AM, you wrote:
>
> BM> Steve Howe wrote:
> >> JC> return OID if sum of all replacement INSERTs in the rule inserted
> >> JC>only one row, else zero
> >> I don't agree with this one since it would lead us to a m
Hello Bruce,
Monday, September 9, 2002, 12:22:26 AM, you wrote:
BM> Steve Howe wrote:
>> JC> return OID if sum of all replacement INSERTs in the rule inserted
>> JC>only one row, else zero
>> I don't agree with this one since it would lead us to a meaningless
>> information... what
Joe Conway wrote:
> Sure, but that's why I am in favor of changing the tag. If you did:
>
> DELETE FROM fooview WHERE name LIKE 'Joe%';
>
> and got:
>
> MUTATED 507324 3
>
> it would mean that 3 tuples in total were affected by all of the
> substitute operations, only of of them being an INSE
Steve Howe wrote:
> We still have to hear the other developers about this, but for a
> while, my votes go to Proposal's #2 (by Tom) and Proposal #3 if enough
> people consider it important.
I think Tom and Hirosh were the people most involved in the previous
discussion.
--
Bruce Momjian
Bruce Momjian wrote:
> Joe Conway wrote:
>>This is basically Tom's proposal, but substituting MUTATED for the
>>original command tag name acknowledges that the original command was not
>> executed unchanged. It also serves as a warning that the affected
>>tuple count is from one or more substi
Hello Bruce,
Monday, September 9, 2002, 12:21:11 AM, you wrote:
BM> Steve Howe wrote:
>> Hello Bruce,
>>
>> But this *is* the total number of rows affected. There is no current
>> (defined) behavior of "rows affected by the same kind of command
>> issued", although I agree it makes some sense.
Hello Bruce,
Monday, September 9, 2002, 12:16:32 AM, you wrote:
BM> Joe Conway wrote:
BM> Any suggestion on how to show the tag mutated? Do we want to add more
BM> tag possibilities?
Again, I don't agree with PQcmdStatus() returning a pseudo-keyword,
since I would expect a SQL command executed
Steve Howe wrote:
> JC> return OID if sum of all replacement INSERTs in the rule inserted
> JC>only one row, else zero
> I don't agree with this one since it would lead us to a meaningless
> information... what would be the number retrieved ? Not an OID, nor
> nothing.
I don't unders
Steve Howe wrote:
> Hello Bruce,
>
> Sunday, September 8, 2002, 10:52:45 PM, you wrote:
>
> BM> I liked option #2. I don't think the _last_ query in a rule should have
> BM> any special handling.
>
> BM> So, to summarize #2, we have:
>
> BM> if no INSTEAD,
> BM> return value
Hello Joe,
Sunday, September 8, 2002, 11:54:45 PM, you wrote:
JC> Bruce Momjian wrote:
>> I liked option #2. I don't think the _last_ query in a rule should have
>> any special handling.
>>
>> So, to summarize #2, we have:
>>
>> if no INSTEAD,
>> return value of original command
Joe Conway wrote:
> Bruce Momjian wrote:
> > I liked option #2. I don't think the _last_ query in a rule should have
> > any special handling.
> >
> > So, to summarize #2, we have:
> >
> > if no INSTEAD,
> > return value of original command
> >
> > if INSTEAD,
> > return tag
Hello Bruce,
Sunday, September 8, 2002, 10:52:45 PM, you wrote:
BM> I liked option #2. I don't think the _last_ query in a rule should have
BM> any special handling.
BM> So, to summarize #2, we have:
BM> if no INSTEAD,
BM> return value of original command
The problem is, this
Bruce Momjian wrote:
> I liked option #2. I don't think the _last_ query in a rule should have
> any special handling.
>
> So, to summarize #2, we have:
>
> if no INSTEAD,
> return value of original command
>
> if INSTEAD,
> return tag of original command
> retu
I liked option #2. I don't think the _last_ query in a rule should have
any special handling.
So, to summarize #2, we have:
if no INSTEAD,
return value of original command
if INSTEAD,
return tag of original command
return sum of all affected rows with
Hello all,
Here are the proposals for solutioning the "Return proper effected
tuple count from complex commands [return]" issue as seen on TODO.
Any comments ?... This is obviously open to voting and discussion.
--
Best regards,
Steve Howe mailto:[EMAIL PROTECTED]
27 matches
Mail list logo
