From pgsql-hackers-owner+M22587@postgresql.org Wed May 8 19:47:28 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g48NlR416874 for ; Wed, 8 May 2002 19:47:27 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id A5D5F475ED7; Wed, 8 May 2002 19:47:18 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 074664762D2; Wed, 8 May 2002 19:38:42 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 54D9A475F6C for ; Wed, 8 May 2002 19:38:32 -0400 (EDT) Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86]) by postgresql.org (Postfix) with ESMTP id 5ACCD476487 for ; Wed, 8 May 2002 19:08:19 -0400 (EDT) Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1]) by localhost.mallet-assembly.org (Postfix) with ESMTP id 8399D12F78C for ; Wed, 8 May 2002 19:08:10 -0400 (EDT) Received: by amanda.mallet-assembly.org (Postfix, from userid 1000) id 0730F12F685; Wed, 8 May 2002 19:08:02 -0400 (EDT) To: pgsql-hackers@postgresql.org Subject: [HACKERS] Queries using rules show no rows modified? From: Michael Alan Dorman Date: 08 May 2002 19:08:01 -0400 Message-ID: <87znzaqlv2.fsf@amanda.mallet-assembly.org> Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR I'm using 7.2.1 on a Debian system. If I do an insert or update or delete on a table, postgres tells me how many rows were affected. Using the following input to psql, I got the results: INSERT 0 0 UPDATE 0 DELETE 0 Is this expected? The principle of least suprise suggests to me that regardless of the query being rewritten, there is some number of tuples being affected, and it would thus still be appropriate to return that number. I realize it's not technically a "bug", since there's no particular guarantee that someone specified existing records or whatnot, but as an additional fourth-string check in some web code I put together, I was checking to see if stuff was returned or updated (since the system should only being allowing changes to things that exist) as a heuristic to guard against 1) bugs, and 2) attempts to maliciously subvert the public interface. I can find no mention of this issue in the documentation regarding the rule system. Anyone have any guidance? Mike. -----8<----- drop sequence member_id_seq; create sequence member_id_seq; drop table member; create table member ( id integer not null constraint member_id primary key default nextval('member_id_seq'), created timestamp not null default now (), modified timestamp not null default now (), deleted timestamp default null, email character varying (128) not null constraint member_email unique, password character varying (128) not null ); drop view members; create view members as select * from member m1 where m1.deleted is null; drop rule members_delete; create rule members_delete as on delete to members do instead update member set deleted = current_timestamp; drop rule members_insert; create rule members_insert as on insert to members do instead insert into member (email, password) values (new.email, new.password); drop rule members_update; create rule members_update as on update to members do instead update member set email = new.email, password = new.password; insert into members (email, password) values ('mdorman@wombat.org','pinochle'); update members set email='mdorman@lemur.org', password='wombat' where id = 1; delete from members where id = 1; ----->8----- ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org From pgsql-hackers-owner+M22589@postgresql.org Wed May 8 20:15:34 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g490FY417439 for ; Wed, 8 May 2002 20:15:34 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id DFD6E4762E1; Wed, 8 May 2002 20:15:21 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 26D52476140; Wed, 8 May 2002 20:15:05 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 86B5947593F for ; Wed, 8 May 2002 20:14:51 -0400 (EDT) Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by postgresql.org (Postfix) with SMTP id 2BA754758F6 for ; Wed, 8 May 2002 20:14:46 -0400 (EDT) Received: (qmail 25269 invoked from network); 9 May 2002 00:14:48 -0000 Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) by sd2.tpf-fw-c.co.jp with SMTP; 9 May 2002 00:14:48 -0000 Received: from tpf.co.jp ([126.0.1.68]) by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id JAA09255; Thu, 9 May 2002 09:14:46 +0900 (JST) Message-ID: <3CD9BFCC.268A52E0@tpf.co.jp> Date: Thu, 09 May 2002 09:16:12 +0900 From: Hiroshi Inoue X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Michael Alan Dorman cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Michael Alan Dorman wrote: > > I'm using 7.2.1 on a Debian system. > > If I do an insert or update or delete on a table, postgres tells me > how many rows were affected. > > Using the following input to psql, I got the results: > > INSERT 0 0 > UPDATE 0 > DELETE 0 > > Is this expected? The principle of least suprise suggests to me that > regardless of the query being rewritten, there is some number of > tuples being affected, and it would thus still be appropriate to > return that number. You are right. It's a bug introduced in 7.2. Please check the thread [GENERAL]([HACKERS]) Using views and MS access via odbc. If there's no objection, I would commit the patch in the thread to both 7.2-stable and the current. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) From pgsql-hackers-owner+M22600@postgresql.org Thu May 9 01:26:14 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g495QD420463 for ; Thu, 9 May 2002 01:26:14 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 1CE274759BC; Thu, 9 May 2002 01:26:14 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 130AE476107; Thu, 9 May 2002 01:25:47 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 8E2AC475EFB for ; Thu, 9 May 2002 01:25:35 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 52D5D475F20 for ; Thu, 9 May 2002 01:24:28 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g495O6W16675; Thu, 9 May 2002 01:24:06 -0400 (EDT) To: Hiroshi Inoue cc: Michael Alan Dorman , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <3CD9BFCC.268A52E0@tpf.co.jp> References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue message dated "Thu, 09 May 2002 09:16:12 +0900" Date: Thu, 09 May 2002 01:24:05 -0400 Message-ID: <16672.1020921845@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue writes: > If there's no objection, I would commit the patch > in the thread to both 7.2-stable and the current. Last I checked, I objected to your solution and you objected to mine ... so I think it's on hold until we get some more votes. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly From pgsql-hackers-owner+M22625@postgresql.org Thu May 9 10:08:57 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49E8u401598 for ; Thu, 9 May 2002 10:08:56 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 69C16476171; Thu, 9 May 2002 10:08:37 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id C9CE1476629; Thu, 9 May 2002 09:58:53 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id C57B4476528 for ; Thu, 9 May 2002 09:58:42 -0400 (EDT) Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86]) by postgresql.org (Postfix) with ESMTP id 2CA4147630F for ; Thu, 9 May 2002 09:56:00 -0400 (EDT) Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1]) by localhost.mallet-assembly.org (Postfix) with ESMTP id E959512F78C for ; Thu, 9 May 2002 09:55:49 -0400 (EDT) Received: by amanda.mallet-assembly.org (Postfix, from userid 1000) id D2B9A12F685; Thu, 9 May 2002 09:55:48 -0400 (EDT) To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> From: Michael Alan Dorman Date: 09 May 2002 09:55:48 -0400 In-Reply-To: <16672.1020921845@sss.pgh.pa.us> Message-ID: <87pu05s9wb.fsf@amanda.mallet-assembly.org> Lines: 57 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane writes: > Last I checked, I objected to your solution and you objected to mine > ... so I think it's on hold until we get some more votes. Well, If I'm reading this code from DBD::Pg's dbdimp.c correctly, I think that the perl module, at least, feels that the number is much more important than the actual command that is returned: if (PGRES_TUPLES_OK == status) { [...] } else if (PGRES_COMMAND_OK == status) { /* non-select statement */ if (! strncmp(cmdStatus, "DELETE", 6) || ! strncmp(cmdStatus, "INSERT", 6) || ! strncmp(cmdStatus, "UPDATE", 6)) { ret = atoi(cmdTuples); } else { ret = -1; } It appears that while the implementation does look to make sure the return string is recognizable, it doesn't care too much beyond that which one it is---not suprising as that string is, as far as the DBI interface is concerned, just "extra information" that has no defined interface to get back out to the user. More important, at least from the standpoint of a user of the module seems to be that the cmdTuples (gotten from PQcmdTuples) represents number affected so it can be returned. In fact, now that I look at it, this change has in fact broken the DBD::Pg interface with respect to the DBI when used in the presence of rules, because the DBI spec states that it will either return the number of tuples affected or -1 if that is unknown, rather than 0, which breaks as a result of this change. I guess there's an argument to be made as to whether PostgreSQL provides any guarantees about this number being correct or even valid, but the fact that the library interface makes it available, and I see nothing in the documentation of the function that suggests that that number is unreliable suggests that it is not an error to depend on it. So, If I understood the proposals correctly, I think that means that this implementation argues for, or at least would work well with, Hiroshi's solution, since yours, Tom, would return a false zero in certain (perhaps rare) situations, arguably loosing information that the perl module, at least, could use, and the library purports to make available, in order to preserve information it does not. I guess there is one other possibility, though I don't know how radical it would be in either implementation or effects: return the empty string from PQcmdTuples in this situation. It serves as something of an acknowledgement that what went on was not necessarily fish or fowl, while still being, from my reading of the docs, a valid return. The perl module certainly regards it as one, albeit one that transmits precious little information. Well-written interfaces should already be able to cope with it, given that it is documented as a possiblity in the docs, right? Mike. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-hackers-owner+M22633@postgresql.org Thu May 9 11:00:49 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49F0m416710 for ; Thu, 9 May 2002 11:00:48 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 62204476171; Thu, 9 May 2002 11:00:43 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 097C44767A0; Thu, 9 May 2002 10:44:34 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 2D9044766F0 for ; Thu, 9 May 2002 10:44:21 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id D786C476306 for ; Thu, 9 May 2002 10:43:27 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g49EhUW19441; Thu, 9 May 2002 10:43:30 -0400 (EDT) To: Michael Alan Dorman cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <87pu05s9wb.fsf@amanda.mallet-assembly.org> References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> Comments: In-reply-to Michael Alan Dorman message dated "09 May 2002 09:55:48 -0400" Date: Thu, 09 May 2002 10:43:30 -0400 Message-ID: <19438.1020955410@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Michael Alan Dorman writes: > So, If I understood the proposals correctly, I think that means that > this implementation argues for, or at least would work well with, > Hiroshi's solution, since yours, Tom, would return a false zero in > certain (perhaps rare) situations, IMHO Hiroshi's solution would return false information in more cases than mine. The basic argument in favor of a patch like this is that if a rule replaces (DO INSTEAD) a command with another command of the same general type, it is useful to return the tag for the replacement command not the original. I agree with that. I do not agree with the claim that we should return a tag from the underlying implementation when a rule rewrites a query into a form totally unrecognizable to the client. Consider again the example of transforming an UPDATE on a view into an INSERT on some underlying table --- but let's reverse it now and suppose it's the other way, the client sends INSERT and the rule replaces it with an UPDATE. If the client is expecting to get back "INSERT m n" and actually gets back "UPDATE n", isn't that client likely to break? Another issue is that the whole thing falls down if the rewriting generates more than one query; both Hiroshi's proposal and mine will not return any substitute tag then. This seems rather restrictive. Maybe we could have behavior like this: if the original command is replaced, then use the tag from the last substituted command of the same class (eg, if you rewrite an UPDATE into an INSERT and an UPDATE, you get the tag from the UPDATE). If there is *no* substitute command of the same class, I still believe that returning "UPDATE 0" is correct behavior. You sent an update, zero tuples were updated, end of story. There is not scope in this API to tell you about how many tuples might have been inserted or deleted. Note that as of CVS tip, the firing order of rules is predictable, so the rule author can control which substituted command is "the last one". Without this I don't think that the above would work, but with it, it seems like a moderately clean answer. Moreover it's at least somewhat compatible with the pre-7.2.1 behavior --- where you got the tag from the last command *executed* regardless of any other considerations. That was definitely broken. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) From pgsql-hackers-owner+M22639@postgresql.org Thu May 9 12:16:27 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49GGP423508 for ; Thu, 9 May 2002 12:16:26 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 0E20447622F; Thu, 9 May 2002 12:16:15 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 3317647656F; Thu, 9 May 2002 12:14:17 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id DBD2B476486 for ; Thu, 9 May 2002 12:14:05 -0400 (EDT) Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86]) by postgresql.org (Postfix) with ESMTP id 95F62476371 for ; Thu, 9 May 2002 12:13:33 -0400 (EDT) Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1]) by localhost.mallet-assembly.org (Postfix) with ESMTP id 2031312F78C for ; Thu, 9 May 2002 12:13:24 -0400 (EDT) Received: by amanda.mallet-assembly.org (Postfix, from userid 1000) id 075D312F685; Thu, 9 May 2002 12:13:22 -0400 (EDT) To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> From: Michael Alan Dorman Date: 09 May 2002 12:13:22 -0400 In-Reply-To: <19438.1020955410@sss.pgh.pa.us> Message-ID: <87y9etqoyl.fsf@amanda.mallet-assembly.org> Lines: 97 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane writes: > The basic argument in favor of a patch like this is that if a rule > replaces (DO INSTEAD) a command with another command of the same > general type, it is useful to return the tag for the replacement > command not the original. I agree with that. I would argue that the argument in favor of a patch is that there's no documentation anywhere that behavior changed, or that PQcmdTuples will not return the expected result in the presence of rules. :-) Is the change behaviorou propose implementable as a patch to 7.2.1? > If the client is expecting to get back "INSERT m n" and actually > gets back "UPDATE n", isn't that client likely to break? Perhaps. How many clients are checking that the string returned matches the query it sent? I've checked DBD::Pg, it doesn't. I've checked psycopg, it doesn't, though it looks like its handling of the value might be a bit bogus. ecpg doesn't, though it looks like it might choke on an empty string. PHP doesn't. QT3 doesn't. PoPY (another Python interface) doesn't. The TCL library doesn't even look at the return, it just passes it back, so I suppose there might be applications doing a direct look. The python lib included with postgresql doesn't. In fact, the idiom is either (in pseudocode): if (temp = PQcmdTuples (result)) { numTuples = atoi (temp); } else { numTuples = some other arbitrary value; } or: numTuples = atoi (PQcmdTuples (result)); So, no, my *very* unscientific and non-comprehensive survey suggests that your fears are mostly groundless. But I haven't seen a single interface that *is* depending on that being correct, but many of them return misleading results if PQcmdTuples does. Which is, if I haven't hammered this enough, not mentioned anywhere in the documentation. > Another issue is that the whole thing falls down if the rewriting > generates more than one query; both Hiroshi's proposal and mine will > not return any substitute tag then. This seems rather restrictive. If, when you say, "will not return any substitute tag then.", you mean that, as an end result PQcmdTuple would return an empty string, well, that seems reasonable---it keeps the DB from returning bogus info, and an empty string returned from PQcmdTuple _is_ documented as a valid response, and it looks like most interfaces would handle it just fine (except maybe for ecpg, which I would argue either has a bug or I'm not reading right). I guess there's the argument to be made that any overly-zealous interface that might choke on getting a different tag back might also choke on getting no tag back. But, again, I don't see any doing any of this. And they *all* seem to expect PQcmdTuples to either return legitimate data or nothing at all. > Maybe we could have behavior like this: if the original command is > replaced, then use the tag from the last substituted command of the > same class (eg, if you rewrite an UPDATE into an INSERT and an > UPDATE, you get the tag from the UPDATE). If there is *no* > substitute command of the same class, I still believe that returning > "UPDATE 0" is correct behavior. You sent an update, zero tuples > were updated, end of story. As long as you document that PQcmdTuples cannot be relied on when using rules, since the rules might change the query sufficiently to make it unrecognizable, that's probably OK, though it'll require significant changes to just about all interface libraries. > Note that as of CVS tip, the firing order of rules is predictable, > so the rule author can control which substituted command is "the > last one". Without this I don't think that the above would work, > but with it, it seems like a moderately clean answer. Moreover it's > at least somewhat compatible with the pre-7.2.1 behavior --- where > you got the tag from the last command *executed* regardless of any > other considerations. That was definitely broken. So should I interpret these references to CVS tip as suggesting that the fix for this change in behavior is not going to be seen until 7.3, or just that a most-complete fix that tries to deal with multi-rule invocations would have to wait for 7.3, but that a fix for the simpler 'do instead' case could show up in a 7.2.X release? Because it seems to me that if we're not going to see a release with a fix for this change in behavior, we need to make sure that maintainers of all interfaces know that all bets are off regarding PQcmdTuples in the (I believe undetectable) presence of rules so they'll make no effort to use it. Mike. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster From pgsql-hackers-owner+M22651@postgresql.org Thu May 9 13:48:04 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49Hm3424831 for ; Thu, 9 May 2002 13:48:03 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 85BBD4764FF; Thu, 9 May 2002 13:48:00 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id A414347676B; Thu, 9 May 2002 13:39:19 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 5F794476652 for ; Thu, 9 May 2002 13:39:05 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 09688475BAD for ; Thu, 9 May 2002 13:35:21 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g49HZKW20799; Thu, 9 May 2002 13:35:20 -0400 (EDT) To: Michael Alan Dorman cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <87y9etqoyl.fsf@amanda.mallet-assembly.org> References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <87y9etqoyl.fsf@amanda.mallet-assembly.org> Comments: In-reply-to Michael Alan Dorman message dated "09 May 2002 12:13:22 -0400" Date: Thu, 09 May 2002 13:35:19 -0400 Message-ID: <20796.1020965719@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Michael Alan Dorman writes: > Tom Lane writes: >> If the client is expecting to get back "INSERT m n" and actually >> gets back "UPDATE n", isn't that client likely to break? > Perhaps. How many clients are checking that the string returned > matches the query it sent? > I've checked DBD::Pg, it doesn't. You are confusing client behavior (by which I meant application) with library behavior. In libpq terms, an application that's sent an INSERT command might expect to be able to retrieve an OID with PQoidValue(). Whether the library avoids core-dumping doesn't mean that the calling app will behave sanely. > I would argue that the argument in favor of a patch is that there's no > documentation anywhere that behavior changed, or that PQcmdTuples will > not return the expected result in the presence of rules. :-) The motivation for making a change was to try to *preserve* pre-7.2 behavior in the case of INSERTs, where formerly you got back an INSERT tag even in the presence of ON INSERT DO not-INSTEAD rules. 7.2 broke that; 7.2.1 fixed that case but changed the behavior for INSTEAD cases. What we're realizing now is that we need an actually designed behavior, rather than the implementation artifact that happened to yield pleasant results most of the time before 7.2. I'm arguing that the "designed behavior" ought to include the stipulation that the tag you get back will match the command you sent. I think that anything else is more likely to confuse clients than help them. > Which is, if I haven't hammered this enough, not mentioned anywhere in > the documentation. Mainly because no one ever designed the behavior; the pre-7.2 implementation didn't really think about what should happen. > I guess there's the argument to be made that any overly-zealous > interface that might choke on getting a different tag back might also > choke on getting no tag back. But, again, I don't see any doing any > of this. And they *all* seem to expect PQcmdTuples to either return > legitimate data or nothing at all. No, you're still missing the point. PQcmdTuples isn't going to dump core, because it has no context about what was expected: it sees a tag and interprets it as best it can, without any idea about what the calling app might be expecting. What we need to think about here is what linkage an *application* can reasonably expect between the command it sends and the tag it gets back (and, hence, the info it can expect to retrieve from the tag). > As long as you document that PQcmdTuples cannot be relied on when > using rules, since the rules might change the query sufficiently to > make it unrecognizable, that's probably OK, though it'll require > significant changes to just about all interface libraries. One more time: there will be zero change in any interface library, no matter what we do here. The libraries operate at too low a level to be affected; they have no idea what command you sent. I'm not even convinced that PQcmdTuples is where to document the issue --- it seems to me to be a rule question, instead. > So should I interpret these references to CVS tip as suggesting that > the fix for this change in behavior is not going to be seen until 7.3, > or just that a most-complete fix that tries to deal with multi-rule > invocations would have to wait for 7.3, but that a fix for the simpler > 'do instead' case could show up in a 7.2.X release? Until we've decided what *should* happen, it's premature to discuss whether we can fix it correctly in 7.2.X or should install a quick-hack change instead. I'd prefer to fix it correctly but we must not let ourselves be seduced by a quick hack into not thinking about what the behavior really ideally ought to be. We've done that once too often already ;-) FWIW, I'm not at all sure that there will *be* any 7.2.2 release before 7.3. There hasn't so far been enough volume of fixes to justify one (no, this problem doesn't justify one IMHO...) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html From pgsql-hackers-owner+M22663@postgresql.org Thu May 9 14:49:40 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49Ind425928 for ; Thu, 9 May 2002 14:49:39 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id CD0D1476627; Thu, 9 May 2002 14:49:37 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 5E96847673E; Thu, 9 May 2002 14:44:15 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 9FD43476470 for ; Thu, 9 May 2002 14:44:04 -0400 (EDT) Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86]) by postgresql.org (Postfix) with ESMTP id BD99947663F for ; Thu, 9 May 2002 14:38:03 -0400 (EDT) Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1]) by localhost.mallet-assembly.org (Postfix) with ESMTP id 4904C12F78C for ; Thu, 9 May 2002 14:37:50 -0400 (EDT) Received: by amanda.mallet-assembly.org (Postfix, from userid 1000) id A06BF12F685; Thu, 9 May 2002 14:37:47 -0400 (EDT) To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <87y9etqoyl.fsf@amanda.mallet-assembly.org> <20796.1020965719@sss.pgh.pa.us> From: Michael Alan Dorman Date: 09 May 2002 14:37:47 -0400 In-Reply-To: <20796.1020965719@sss.pgh.pa.us> Message-ID: <87znz9p3pg.fsf@amanda.mallet-assembly.org> Lines: 71 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane writes: > You are confusing client behavior (by which I meant application) > with library behavior. In libpq terms, an application that's sent > an INSERT command might expect to be able to retrieve an OID with > PQoidValue(). Whether the library avoids core-dumping doesn't mean > that the calling app will behave sanely. No, Tom, I'm not confusing them. I'm in no way concerned with PQcmdTuple coredumping because the published interface specifies that it can return a null string if it finds it necessary, which implies that somewhere down there it's doing some decent error handling to figure out if it's gotten something back it can make sense of and acting appropriately. You brought up core dumps. My concern has been exclusively with the potential change in behavior this can cause in applications. So I've been doing is going and downloading the source to, and looking at the behavior of, some of the libraries that some---probably many, maybe even most---clients are using, those for perl and python and php, and I am finding that most of them do not even expose the information whose (mis-)interpretation concerns you. So, for those interfaces, at least, there was no problem to be fixed in the first place. Still, you don't have to have something actively breaking to warrant fixing a bug, so there's no reason to have not made the change that was made. The problem is that, at the same time, I am finding that the change to postgresql 7.2 may make application code using those interfaces begin to operate in new and different ways because, although they aren't paying attention to the string, which you are concerned with, they *are* paying attention to the numbers. Many of those interfaces, where they used to return 1 or 10 or 5000 or 6432456, will now be returning 0, which thanks to the great C tradition, is often interpreted to mean "false", which may lead an application to question why "nothing happened." As mine did. And this isn't necessarily application programmers making bad choices; the Perl interface, at least, documents the fact that it returns the number of rows affected or -1 if that is unknowable---but the change in behavior leads the perl interface to think it knows, when in fact it doesn't. If I knew java better, I'd check the JDBC driver. I mean, imagine: Perl, python, php and java, all with undocumented unpredictable behavior in the presence of 'update do instead' rules. Break all four and you've just created a potential problem for everyone who does web development. That, I think, is one of the more egregious changes in behavior I've seen in the few years I've been following PostgreSQL, and yet not only is there any documentation, I feel like I'm having to fight to even get it acknowledge that it is the bigger problem than the blasted strings not matching because it affects a heck of a lot more stuff in a much more direct manner. Still, handle this however you want. I'll go fix the Perl driver to pretend PQcmdTuples doesn't exist, since it can't be trusted to deliver reliable information, and just have it return -1, and *my* apps will be OK. Maybe some months down the road when 7.3 finally straggles into view there will be a solution. Hopefully no one will have been burned. Anyway, I'm done beating this dead horse, since the display is obviously bothering people. Mike. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster From pgsql-hackers-owner+M22695@postgresql.org Thu May 9 21:16:21 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4A1GK400881 for ; Thu, 9 May 2002 21:16:20 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id ADD4F4767FA; Thu, 9 May 2002 21:16:06 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 643D247691E; Thu, 9 May 2002 21:15:49 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 4B0CF47630B for ; Thu, 9 May 2002 21:15:29 -0400 (EDT) Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by postgresql.org (Postfix) with SMTP id B9FB2475F13 for ; Thu, 9 May 2002 21:15:22 -0400 (EDT) Received: (qmail 1794 invoked from network); 10 May 2002 01:15:25 -0000 Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) by sd2.tpf-fw-c.co.jp with SMTP; 10 May 2002 01:15:25 -0000 Received: from tpf.co.jp ([126.0.1.68]) by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id KAA09847; Fri, 10 May 2002 10:15:23 +0900 (JST) Message-ID: <3CDB1F82.BFE2CC5C@tpf.co.jp> Date: Fri, 10 May 2002 10:16:50 +0900 From: Hiroshi Inoue X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane cc: Michael Alan Dorman , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane wrote: > > Michael Alan Dorman writes: > > So, If I understood the proposals correctly, I think that means that > > this implementation argues for, or at least would work well with, > > Hiroshi's solution, since yours, Tom, would return a false zero in > > certain (perhaps rare) situations, > > IMHO Hiroshi's solution would return false information in more cases > than mine. My solution never returns false information as to patched cases though the returned result may be different from the one clients expect. Probably your solution doesn't return false information either if 'UPDATE 0' means UPDATE 0 but unknown INSERT/DELETEs. But few(maybe no ?) clients seem to think of it and what could clients do with such infos in the first place ? 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). regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-hackers-owner+M22696@postgresql.org Thu May 9 21:28:00 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4A1S0400995 for ; Thu, 9 May 2002 21:28:00 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 8D3EC4768F7; Thu, 9 May 2002 21:27:54 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id C60E347686A; Thu, 9 May 2002 21:27:40 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 9DDB6475EF2 for ; Thu, 9 May 2002 21:27:22 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 8D51A475D9D for ; Thu, 9 May 2002 21:27:21 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4A1R8W24994; Thu, 9 May 2002 21:27:08 -0400 (EDT) To: Hiroshi Inoue cc: Michael Alan Dorman , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <3CDB1F82.BFE2CC5C@tpf.co.jp> References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <3CDB1F82.BFE2CC5C@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue message dated "Fri, 10 May 2002 10:16:50 +0900" Date: Thu, 09 May 2002 21:27:08 -0400 Message-ID: <24991.1020994028@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue 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. I'm also concerned about having an understandable definition for the OID returned for an INSERT query --- if there are additional INSERTs triggered by rules, does that mean you don't get to see the OID assigned to the single row you tried to insert? You'll definitely get push-back if you propose that. But if we add up all the actions for the generated queries, we are quite likely to be returning an OID along with an insert count greater than one --- which is certainly confusing, as well as contrary to the existing documentation about how it works. Let's please quit worrying about "can we install a hack today" and instead try to figure out what a sensible behavior is. I don't think it's likely to be hard to implement anything we might come up with, considering how tiny this API is. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html From pgsql-hackers-owner+M22699@postgresql.org Thu May 9 22:36:27 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4A2aR401628 for ; Thu, 9 May 2002 22:36:27 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id EECB1476843; Thu, 9 May 2002 22:36:22 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 2B1B34768E5; Thu, 9 May 2002 22:35:39 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 267D2476860 for ; Thu, 9 May 2002 22:35:28 -0400 (EDT) Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by postgresql.org (Postfix) with SMTP id 1BE8447590B for ; Thu, 9 May 2002 22:34:30 -0400 (EDT) Received: (qmail 10177 invoked from network); 10 May 2002 02:34:34 -0000 Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) by sd2.tpf-fw-c.co.jp with SMTP; 10 May 2002 02:34:34 -0000 Received: from tpf.co.jp ([126.0.1.68]) by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id LAA09898; Fri, 10 May 2002 11:34:33 +0900 (JST) Message-ID: <3CDB320F.55B00318@tpf.co.jp> Date: Fri, 10 May 2002 11:35:59 +0900 From: Hiroshi Inoue X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane cc: Michael Alan Dorman , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <3CDB1F82.BFE2CC5C@tpf.co.jp> <24991.1020994028@sss.pgh.pa.us> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane wrote: > > Hiroshi Inoue 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. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-hackers-owner+M22704@postgresql.org Fri May 10 06:34:07 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4AAY6406914 for ; Fri, 10 May 2002 06:34:07 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id E649F476131; Fri, 10 May 2002 06:33:54 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 77EB447672A; Fri, 10 May 2002 06:30:40 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id A391F4762CD for ; Fri, 10 May 2002 06:30:24 -0400 (EDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by postgresql.org (Postfix) with SMTP id 75A4A47620B for ; Fri, 10 May 2002 06:30:18 -0400 (EDT) Received: from h00045a2e4e7c.ne.client2.attbi.com (HELO saturn.janwieck.net) (janwieck@24.61.137.137 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 May 2002 10:30:19 -0000 Received: (from wieck@localhost) by saturn.janwieck.net (8.11.2/8.11.2) id g4AAJGD03410; Fri, 10 May 2002 06:19:16 -0400 From: Jan Wieck Message-ID: <200205101019.g4AAJGD03410@saturn.janwieck.net> Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <24991.1020994028@sss.pgh.pa.us> from Tom Lane at "May 9, 2002 09:27:08 pm" To: Tom Lane Date: Fri, 10 May 2002 06:19:16 -0400 (EDT) cc: Hiroshi Inoue , Michael Alan Dorman , pgsql-hackers@postgresql.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: ORr Tom Lane wrote: > Hiroshi Inoue 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@Yahoo.com # ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly From pgsql-hackers-owner+M22723@postgresql.org Fri May 10 10:56:10 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4AEu9418485 for ; Fri, 10 May 2002 10:56:09 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id AA205475C2C; Fri, 10 May 2002 10:55:46 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id E96B447667B; Fri, 10 May 2002 10:51:45 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id D46CF475A00 for ; Fri, 10 May 2002 10:51:34 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 09489475A04 for ; Fri, 10 May 2002 10:51:30 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4AEp5W28246; Fri, 10 May 2002 10:51:06 -0400 (EDT) To: Hiroshi Inoue cc: Michael Alan Dorman , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <3CDB320F.55B00318@tpf.co.jp> References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <3CDB1F82.BFE2CC5C@tpf.co.jp> <24991.1020994028@sss.pgh.pa.us> <3CDB320F.55B00318@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue message dated "Fri, 10 May 2002 11:35:59 +0900" Date: Fri, 10 May 2002 10:51:05 -0400 Message-ID: <28243.1021042265@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue writes: > What should the backends return for complicated rewrites ? Well, given that we have only two or three fields to work in, it obviously has to be a very simplified view of what happened. But we have to define *something*. > And how should/could clients handle the results ? > It doesn't seem easy to me and it seems a flaw of rule > system. No, the problem is that the command tag API was designed without any thought for rule rewriting. But I don't think it's worth revising that API completely. Even if we did, we'd still have to define what behavior would be seen by clients that use the existing PQcmdTuples, etc, calls; so we'd still have to solve these same issues. Come on, guys, work with me a little here. I've thrown out several alternative suggestions already, and all I've gotten from either of you is refusal to think about the problem. I was thinking last night that it might help to break down the issue a little bit. We have either two or three result fields to think about: the tag name, the tuple count, and in the case of INSERT the inserted row OID. Let's consider each one independently. 1. The tag name: AFAICS, this ought *always* to match the type of the original command submitted by the client. Doing otherwise could confuse clients that are submitting multiple commands per query string. Besides, the only possible downside from making this requirement is that we couldn't send back an insertion OID when the original command was an update or delete. How likely is it that a client would expect to be able to get an insertion OID from such a command? 2. The inserted row OID: per above, will be supplied only if the original command was an INSERT. If the original insert command is not removed (no INSTEAD rule), then I think this result should clearly come from the execution of the original command, regardless of any additional INSERTs added by rules. If the original command is removed by INSTEAD, then we can distinguish three sub-cases: a. No INSERTs in rewriter output: easy, we must return 0. b. Exactly one INSERT in rewriter output: pretty easy to agree that we should return this command's result. c: More than one INSERT in rewriter output: we have a couple of possibilities here. It'd be reasonable to directly use the result of the last INSERT, or we could total the results of all the INSERTs (ie, if taken together they insert a sum total of one row, return that row OID; else return 0). Maybe there are other possible behaviors. Any thoughts? 3. The tuple count: this seems the most contentious issue. Again, if there is no INSTEAD rule I'd be strongly inclined to say we should just return the count from the original command, ignoring any commands added by rules. If there is an INSTEAD, we've discussed several possibilities: use result of last command in the rewritten series, use result of last command of same type as original command, sum up the results of all the rewritten commands, maybe some others that I forgot. Given Michael's concern about being able to "tell that something happened", I'm inclined to go with the summing-up behavior in the INSTEAD cases. This would lead to the following boiled-down behavior: A. If original command is executed (no INSTEAD), return its tag as-is, regardless of commands added by rules. B. If original command is not executed, then return its tag name plus required fields defined as follows: tuple count is sum of tuple counts of all replacement commands. For an INSERT, if the replacement commands taken together inserted a grand total of exactly one tuple, return that tuple's OID; else return 0. This is not completely consistent in pathological cases: you could get a tuple OID returned even when the returned tuple count is greater than one, which is not a possible case currently. (This would happen given a rewrite consisting of a single-row INSERT plus additional update or delete actions that affect some rows.) But that seems pretty oddball. In all the simple cases I think this proposal gives reasonable behavior. A tighter definition for case B would use the sum of the tuple counts of only the replacement actions that are of the same type as the original command. This would eliminate the possible inconsistency between tuple count and insert OID results, and it's arguably saner than the above proposal: "if it says UPDATE 4, that should mean that four rows were updated, not that something else happened to four rows". But it would not meet Michael's concern about using PQcmdTuples to tell that "something happened". I could live with either definition. Thoughts, different proposals, alternative ways of breaking down the problem? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-hackers-owner+M22899@postgresql.org Thu May 16 16:31:02 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4GKV2B23639 for ; Thu, 16 May 2002 16:31:02 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id EDDEF4762F9; Thu, 16 May 2002 16:30:59 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 52CE1476519; Thu, 16 May 2002 16:30:28 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 92A34475C8A for ; Thu, 16 May 2002 16:30:14 -0400 (EDT) Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86]) by postgresql.org (Postfix) with ESMTP id 0E8A3475BBE for ; Thu, 16 May 2002 16:30:13 -0400 (EDT) Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1]) by localhost.mallet-assembly.org (Postfix) with ESMTP id DDA4412F78C for ; Thu, 16 May 2002 16:30:03 -0400 (EDT) Received: by amanda.mallet-assembly.org (Postfix, from userid 1000) id CF2A912F685; Thu, 16 May 2002 16:30:01 -0400 (EDT) To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? References: <200205101019.g4AAJGD03410@saturn.janwieck.net> <28286.1021042653@sss.pgh.pa.us> From: Michael Alan Dorman Date: 16 May 2002 16:30:01 -0400 In-Reply-To: <28286.1021042653@sss.pgh.pa.us> Message-ID: <874rh7rg3a.fsf@amanda.mallet-assembly.org> Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Tom Lane writes: > Michael seems to feel that the tuple count should be nonzero if any > of the replacement operations did anything at all. This does not > make a lot of sense at the command tag level ("UPDATE 4" might not > mean that 4 tuples were updated) but if you look at the definition > of PQcmdTuples ("returns the number of rows affected by the SQL > command") it's not so unreasonable. And I can see the point of > wanting to know whether anything happened. Close. It's not so much that I want to know exactly what happened, it's that I want to know that if PostgreSQL says nothing happened, then I can be sure that nothing happened, rather than being told that nothing happened when something happened, and vice versa. In fact, my suggestion---which might suffer from issues that I am not aware of, perhaps the ones that led to the patch in the first place---would be that, given ambiguity, have the system return something that would cause PQcmdTuples to return an empty string (I'm assuing this would be a result string with no numbers attached at all). It is documented, after all, as being the return value when the system cannot determine an otherwise correct number, and all of the code I looked at would, I believe, cope gracefully with it, returning what I'm guessing (except in the Perl case, where I'm sure) is a sentinel value indicating, "it worked, but I have no idea how many tuples were involved". But I'm not wedded to that---I just don't want to get an answer back that might lead me off into the woods. As for the issue of whether the tag is the same or not, I am utterly pragmatic---I don't use it, and don't really have a way to get to it from the interfaces I use, so I think the best option is probably something where the rules to describe it are straightforward to minimize confusion and support issues. And it should be documented appropriately. I mean, even when this is resolved, we should probably be putting something in the documentation that says that PQcmdTuples can really only really be depended upon as a tri-state value: 0 ("nothing happened"), >0 ("something happened"), empty string ("heck if I know"). Mike. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org From pgsql-hackers-owner+M22911@postgresql.org Fri May 17 13:56:43 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4HHugB12591 for ; Fri, 17 May 2002 13:56:43 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id D1FCF475FB7; Fri, 17 May 2002 13:44:22 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 391334765F6; Fri, 17 May 2002 13:37:17 -0400 (EDT) Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id ADCE94764EF for ; Fri, 17 May 2002 13:37:04 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 6E63F476886 for ; Fri, 17 May 2002 12:59:21 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4HDV8W03879; Fri, 17 May 2002 09:31:08 -0400 (EDT) To: "Zeugswetter Andreas SB SD" cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Queries using rules show no rows modified? In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA4961DD1@m0114.s-mxs.net> References: <46C15C39FEB2C44BA555E356FBCD6FA4961DD1@m0114.s-mxs.net> Comments: In-reply-to "Zeugswetter Andreas SB SD" message dated "Fri, 17 May 2002 08:53:04 +0200" Date: Fri, 17 May 2002 09:31:08 -0400 Message-ID: <3876.1021642268@sss.pgh.pa.us> From: Tom Lane Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: ORr "Zeugswetter Andreas SB SD" writes: > Tom Lane writes: >> Michael seems to feel that the tuple count should be nonzero if any >> of the replacement operations did anything at all. > Here we usually add triggers, for replication, accounting, setting of > calculated rows ... In all of our cases we want the addition of a trigger > (or rule on a table) to be transparent to the client. Yeah. Triggers wouldn't affect this anyway, unless they tell the system to suppress insertion/update/deletion of some tuples, in which case I think it is correct not to count those tuples (certainly that's how the code has always acted). As far as rules go, the last proposal that I made would return the tuple count of the original query as long as there were no INSTEAD rules --- if you have only actions *added* by rules then they are transparent. The hard case is where the original query is not executed because of an INSTEAD rule. As the code presently stands, you get "UPDATE 0" (or INSERT or DELETE 0) in that case, regardless of what else was done instead by the rule. I thought that was OK when we put the change in, but it seems clear that people do not like that behavior. The notion of "keep it transparent" doesn't seem to help here. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster