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
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
> 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
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
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
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
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
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
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
14 matches
Mail list logo
