From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Steve Howe <howe(at)carcass(dot)dhs(dot)org> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: Solving the "Return proper effected tuple |
Date: | 2002-09-09 03:39:20 |
Message-ID: | 200209090339.g893dKT25023@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 meaningless
> >> information... what would be the number retrieved ? Not an OID, nor
> >> nothing.
>
> 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 at least one OID
> for the last inserted row. With this info, I would be able to refresh
> my client dataset to reflect the new inserted rows.
>
> I see returning 0 if multiple INSERT commands issued is as weird as
> returning some OID if multiple INSERT commands issued. But the second
> options is usable, while the first one is useless... So I would prefer
> retrieving the last inserted OID.
We would return 0 for oid and an insert count, just like INSERT INTO ...
SELECT. How is that weird?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-09-09 03:43:03 | Re: Proposal: Solving the "Return proper effected tuple |
Previous Message | Steve Howe | 2002-09-09 03:37:39 | Re: Proposal: Solving the "Return proper effected tuple count |